ClaudeChatGPTPerplexityGeminiMicrosoft CopilotRaycastMeta AIGrokZ.aiQwenKimi
DeepSeekMistralCursorVS CodeWindsurfJetBrainsClineLovableVercel AI SDKLangChain

Use Technical Writing Prover with your AI.

Connect your account once and let the AI you already use work with it, without building another integration. An AI wrote API documentation for 'developers.' No expertise level. No prerequisites. A wall of text with no headings. Code examples that referenced a deprecate

Included with plan

Ask AI about this Connector

Developed, maintained, and hosted by Vinkius.

MCP VERIFIED · PRODUCTION READY · VINKIUS GUARANTEED

Waiting for input…

Works with modern AI clients that support MCP, including ChatGPT, Claude, Cursor, and more.

ChatGPTClaudeCursorPerplexityGeminiMicrosoft CopilotRaycastMeta AI

Complete set · 1 capability

The complete Technical Writing Prover capability set.

These are the exact actions your AI can choose when you ask it to work with Technical Writing Prover.

Capability set01 / 01

01

1 capability in this set.

Part of 1 available through Technical Writing Prover.

  1. 01

    Validate technical writing

    You must: (1) define the SPECIFIC reader. role, expertise level, prerequisites, goal, (2) structure with Diátaxis classification, task-based headings, and progressive disclosure, (3) provide complete, copy-pasteable code examples with expected output and tested versions, (4) eliminate passive voice, undefined pronouns, and undefined terms, (5) verify prerequisites are listed, error paths documented, edge cases covered, and next steps linked. If rejected, fix the specific documentation gap the engine identifies. Structured reflection capability that forces the LLM to prove technical documentation meets professional standards. defined audience, task-based structure, working examples, eliminated ambiguity, and verified completeness. Based on the Diátaxis framework (Daniele Procida, 2017): documentation has exactly 4 types. tutorials (learning-oriented), how-to guides (task-oriented), reference (information-oriented), and explanations (understanding-oriented). Mixing these types creates confused documents. Catches Audience Undefined (writing for "everyone" = writing for no one. a pharmaceutical label reads: "Take as needed for pain relief. May cause adverse events." "As needed". how often? Maximum dose? Interval? "Adverse events". what kind? Headache? Organ failure? Death? The label was written for "patients". but a 22-year-old athlete and a 78-year-old with liver disease need fundamentally different information. For the athlete: dosing schedule and interaction with supplements. For the elderly patient: maximum daily dose, interaction with blood thinners, renal dosing adjustment. One label for both = inadequate for both. Fix: define the SPECIFIC reader. role, expertise, prerequisites, goal. BEFORE writing), Structure Absent (wall of text without task-based organization. a fire escape diagram is posted in a hotel hallway. It shows all 8 floors, all stairwells, all exits. on one diagram. No floor numbers labeled. No "YOU ARE HERE" marker. No step-by-step evacuation route. Guest at 3am, smoke in hallway: looks at diagram, cannot find their floor, cannot identify direction. Fix: ONE diagram per floor. "YOU ARE HERE" marked. Arrows showing the route to the nearest exit. Step 1: Exit room, turn LEFT. Step 2: Follow hallway to Stairwell B. Step 3: Descend to ground floor. Task-based structure: the reader has ONE task (get out alive). Every element serves that task), Examples Missing (concepts without working demonstrations. an IKEA assembly instruction shows Step 7: "Attach Part K to Frame Assembly using Cam Lock." Problem: Part K is not in the parts list. Not in the hardware bag. Not in any diagram. The customer cannot identify Part K. Step 7 is impossible to execute. The instruction assumed the reader would know what Part K is. They do not. Fix: every referenced part must appear in the parts inventory with a photograph, size, and quantity. Every step must be executable with only the materials provided. If Step 7 references Part K: Part K must exist, be identifiable, and be available), Ambiguity Present (passive voice and undefined terms causing dangerous misinterpretation. an aircraft maintenance manual reads: "The bolt should be tightened." Which bolt? (there are 47 bolts in this assembly). To what torque? "Should be". is it mandatory or recommended? A technician interprets "tightened" as hand-tight (5 Nm). The specification requires 45 Nm. Result: bolt fails under vibration. Component separates during flight. FAA Advisory Circular AC 43.13-1B mandates specific, active-voice maintenance documentation. Fix: "Torque bolt P/N AN3-12A to 45 ± 2 Nm using calibrated torque wrench." Active voice. Specific part number. Exact specification. Measurable tolerance. Rule: if two technicians could interpret the same sentence differently, the sentence will be interpreted wrong by one of them), and Completeness Gaps (missing prerequisites, error paths, or edge cases. a vaccine consent form explains: "This vaccine may cause mild side effects." "Mild". according to whom? "Side effects". which ones? For how long? When to call a doctor? Complete version: "Common effects (>10% of recipients): injection site soreness (1-3 days), fatigue (1-2 days), headache (1 day). Uncommon (1-10%): low-grade fever (< 38.5°C, 1 day). Rare (<0.1%): severe allergic reaction. seek emergency care if: difficulty breathing, facial swelling, rapid heartbeat within 30 minutes of injection." Every claim has a frequency. Every symptom has a duration. Every emergency has an action. The reader knows: what to expect, when to wait, and when to seek help). Call once per documentation, guide, or technical writing review

Observed, not estimated

793ms average. Fast in production.

Technical Writing Prover is checked daily against the live service.

Daily averagePeak 981ms
Aug 26Today
Fastest day
664ms
Slowest day
981ms
14-day trend
Stable-4%

Connect your client

One URL. Every client.

Activate the Connector, copy your link, and paste it into the client you already use. 1 capability arrives ready to run.

Preview access · not provider authentication

The vk_preview_* token belongs to Vinkius preview infrastructure. It lets Claude discover and display the capabilities of Technical Writing Prover, so you can see the experience inside your AI.

It does not authenticate your account with Technical Writing Prover. Actions requiring credentials or live account data may not run until you activate the Connector and authorize the service.

Technical Writing Prover Connector

You're all set. Choose your MCP client and follow the setup instructions.

Connector linkhttps://edge.vinkius.com/vk_preview_OWaZOabijYQqiXzNKgOGtWneCoMKT68VO6tDqnNd/mcp

Claude Desktop

Follow the steps below to connect in seconds.

  1. 1In Claude Desktop, open Settings → Connectors.
  2. 2Click “Add custom connector” and paste the connector link above as the remote MCP server URL.
  3. 3Click Add and start a new chat — Technical Writing Prover capabilities are ready to use.
Configuration · claude_desktop_config.jsonCopy
{
  "mcpServers": {
    "technical-writing-prover-mcp": {
      "url": "https://edge.vinkius.com/vk_preview_OWaZOabijYQqiXzNKgOGtWneCoMKT68VO6tDqnNd/mcp"
    }
  }
}
  • Claude
  • ChatGPT
  • Cursor
  • VS Code
  • Windsurf
  • Claude Code
  • JetBrains
  • Cline

Step-by-step instructions for each client are in the guide. How to connect

FAQ

Questions Technical Writing Prover owners ask.

  • 01

    Does it write documentation?

    No. It validates that documentation meets five quality standards. defined audience, task-based structure, working examples, eliminated ambiguity, and verified completeness. It does not generate text. It forces you to prove your text is publication-ready.

  • 02

    What is the Diátaxis framework?

    Diátaxis classifies documentation into four types based on reader need: tutorials (learning-oriented, guided steps), how-to guides (task-oriented, goal-focused), reference (information-oriented, API specs), and explanation (understanding-oriented, conceptual). Each type has different structural requirements. Mixing them produces documentation that serves none well.

  • 03

    Can it validate non-code documentation like architecture decision records?

    Yes. For conceptual documents (ADRs, RFCs, design docs), the examplesWorking pivot applies to illustrative diagrams, data flow descriptions, or before/after comparisons instead of code blocks. The capability adapts to the document type. but the other four pivots (audience, structure, ambiguity, completeness) apply to every technical document regardless of type.