# DevRel Voice Prover MCP > DevRel Voice Prover validates technical communication by forcing an authentic developer-to-developer tone. It checks content against five axes: community context, actionable code paths, and genuine technical value. Stop writing marketing fluff; get release notes that sound like an engineer talking to a peer. ## Overview - **Category:** productivity - **Price:** Free - **Tags:** devrel, developer-relations, community-management, developer-advocacy, changelog, release-notes, developer-communication, agentic-pipeline ## Description Writing dev documentation is hard because the line between communicating genuinely useful information and sounding like corporate hype is razor thin. This MCP helps your AI agent figure out which side you're on. It takes raw content, whether it’s a changelog or a release note, and forces it through five critical checks to make sure it speaks the language of engineers. You don't get generic text here; you get specific corrections. For instance, if you just say 'We added X,' this MCP flags that as a feature dump and demands you explain what pain point X solves or how it changes their existing workflow. It also makes sure you cite actual community signals—like a specific GitHub issue number or Discord thread ID—instead of vaguely stating 'the community asked for it.' If the content doesn't pass these rigorous, human-level checks, your agent knows to rewrite it until it sounds right. You connect this MCP through Vinkius and let your AI client do the heavy lifting on tone and context. ## Tools ### validate_devrel_voice This tool analyzes content to confirm the tone is peer-to-peer, demanding specific references to community issues, technical value, and runnable code examples. ## Prompt Examples **Prompt:** ``` We are thrilled to announce v3.0 of our innovative platform! This game-changing release features a best-in-class API, seamless integrations, and a robust, scalable architecture. Try it today! ``` **Response:** ``` Verdict: CORPORATE_SPEAK. Every sentence is a marketing buzzword: 'thrilled', 'innovative', 'game-changing', 'best-in-class', 'seamless', 'robust and scalable'. This reads like a LinkedIn ad, not DevRel. No community context (why v3?), no developer value (what problems solved?), no code (how to migrate?), no feedback channel. Rewrite: 'v3.0 is live. The new API resolves the auth token race condition from issue #189. Migration: `npm install @sdk@3.0.0` — see docs.example.com/v3/mig... ``` **Prompt:** ``` Content: changelog for SDK v2.4. Community: issues #312 and #345 reported auth token expiration wasn't handled gracefully — users got silent 401s with no error message. 23 upvotes on feedback board. Value: SDK now auto-refreshes tokens before expiration and surfaces clear error messages with retry guidance when refresh fails. Before: developers had to build their own token refresh logic and catch opaque 401s. Now: zero-config token lifecycle management. Code: `import { createClien... ``` **Response:** ``` Verdict: DEVREL_PROVEN. Developer voice (direct, technical, no buzzwords). Community-aware (issues #312, #345, 23 upvotes). Value articulated (before: manual token refresh + opaque 401s → now: zero-config auto-refresh). Action path (runnable code, opt-in flag, no breaking changes). Authentic (specific issue numbers, before/after comparison, honest about the problem). This is how DevRel communicates. Ship it. ``` **Prompt:** ``` v2.5 release notes. We heard from the community about these needs. Added: GraphQL subscriptions, new rate limiter middleware, database connection pooling, improved error messages, dark mode for dashboard. These features make the platform better. Try them out and let us know what you think! ``` **Response:** ``` Verdict: FEATURE_DUMP. Developer voice is acceptable (no buzzwords), community vaguely referenced ('we heard from the community' — but WHICH community signals? No issue numbers, no Discord threads, no feedback votes). Critical failure: pure feature list without WHY. 'Added GraphQL subscriptions' — SO WHAT? Why does a developer care? Was polling killing performance? Was issue #189 about real-time updates? 'Improved error messages' — improved HOW? Before: 'Error 500'. After: 'Postgr... ``` ## Capabilities ### Enforce Peer Tone The tool rewrites content to eliminate corporate buzzwords, ensuring the writing sounds like a senior engineer talking to another peer. ### Cite Community Sources It forces the inclusion of specific community signals, such as GitHub issue numbers or Discord thread links, grounding the announcement in reality. ### Articulate Technical Value The MCP demands that content explain *why* a feature matters to developers—what pain it eliminates or what workaround it removes. ### Generate Actionable Paths It ensures the output includes runnable code examples, migration commands, and clear setup steps so the developer knows exactly what to do next. ## Use Cases ### Writing the v2.5 Changelog A release engineer needs to write notes for a major API update. Using this MCP ensures they don't just list new endpoints; they explain which existing workflow was broken and provide runnable code snippets showing the fix. ### Announcing an Auth Fix A team fixes a tricky authentication bug that caused silent 401 errors. Running this MCP ensures the announcement references the exact issue numbers and provides the minimal working example to resolve it, keeping users from guessing. ### Creating a New Tutorial A developer writes a guide on integrating a new service. The MCP checks for community awareness, forcing them to reference specific feedback votes or existing threads that led to the integration's design choices. ## Benefits - Stops the use of buzzwords. The `validate_devrel_voice` tool eliminates 'innovative,' 'best-in-class,' and other empty corporate speak, keeping your tone direct and technical. - Guarantees community grounding. Instead of saying 'the community wants this,' you must cite specific sources like GitHub issue numbers or Discord threads for credibility. - Focuses on the problem, not the feature. It forces you to explain the pain point that was eliminated, making your content useful instead of just descriptive. - Requires a clear next step. The MCP ensures every piece of communication provides an action path: runnable code, a migration command, or direct docs link. - Builds trust through honesty. By requiring vulnerability and specific references to past conversations, you build credibility that generic announcements lack. ## How It Works The bottom line is, it fixes your content so it sounds like an engineer wrote it for another engineer. 1. You feed your agent the draft content—the release notes, changelog, or announcement text. 2. The MCP runs five deep checks: checking for buzzwords, verifying community citations, proving technical value, and demanding runnable code paths. 3. Your agent receives a corrected version of the text that is technically sound and speaks directly to developer needs. ## Frequently Asked Questions **Does this tool write DevRel content?** No. The agent writes the content. The tool VALIDATES that it communicates like authentic DevRel — developer voice, community awareness, value articulation, actionable paths, and authentic engagement. It catches the five failure modes that make AI-generated developer communications sound like press releases. **What types of content does it validate?** Changelogs, release notes, blog posts, tutorials, migration guides, breaking change notices, community updates, retrospectives, roadmap updates, incident postmortems, feature announcements, deprecation notices, getting started guides, and API/SDK updates. Each type has different tone, urgency, and structure requirements that the tool validates. **Why does the tool reject 'We are excited to announce'?** Because developers don't care about your excitement — they care about their problems. 'We are excited to announce' is corporate speak that signals 'marketing wrote this.' DevRel says: 'We shipped WebSocket support because issue #247 showed polling was killing your API rate limits. Here's how to migrate in 3 steps.' Direct, technical, problem-focused. That's what builds trust. **When I use `validate_devrel_voice`, what specific types of community signals must I include to pass the context check?** You must cite concrete evidence like GitHub issue numbers or Discord thread links. The tool requires source citations, not vague statements like 'the community wanted this.' Providing these specific references proves authenticity and credibility. **How does `validate_devrel_voice` force me to articulate developer value instead of just creating a feature dump?** It analyzes your text for the 'before and after' scenario. You can't simply list features; you must explain what pain point is eliminated or how a current workaround is removed by the new functionality. **Does running `validate_devrel_voice` slow down if I submit very large technical documents?** The tool processes content efficiently, focusing strictly on validating the five required axes of communication. It doesn't analyze for general grammar but rather structural elements like runnable code and community context. **When using `validate_devrel_voice`, does the actionable path requirement accept pseudocode or conceptual examples?** No, the tool demands a minimal working example. The action path must contain actual, executable code—not just descriptive blocks or pseudo-code—so developers can copy and run it immediately. **Can I use `validate_devrel_voice` for release notes written in languages other than English?** Yes, the underlying mechanism supports multiple natural languages. As long as you provide the community context and technical details specific to that language's development process, the tool can validate its structure.