Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@draft-mcp-server Draft a PR description for the auth changes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Review AI-generated drafts before they go anywhere.
When your AI assistant writes a PR description, ticket, or message, this MCP server opens a review window first. You see a live preview, make edits if needed, and approve or reject.
Claude Code:
claude mcp add draft-mcp-server -- npx draft-mcp-serverClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"draft-mcp-server": {
"command": "npx",
"args": ["draft-mcp-server"]
}
}
}Related MCP server: GitLab MCP Server
Ask your assistant to draft something:
"Draft a PR description for the auth changes"
"Write a Linear ticket for the login bug"
"Draft a Slack message about the release"The review window opens. Edit the text on the left, see the preview on the right. Click Approve or press ⌘ Enter.
⌘ Enter / Ctrl Enter — Approve
Esc — Reject
⌘ C / Ctrl C — Copy to clipboard
MIT
Let the user review and edit a draft before it goes anywhere.
When creating PR descriptions, Linear tickets, Slack messages, or emails: call this tool first, then use the approved content with the target tool.
Opens a browser window with an editor and live preview. Blocks until the user approves or rejects.
On approve: proceed with the next step (create PR, post ticket, etc.) or copy to clipboard. On reject: ask the user what they'd like to change.
Examples:
review_draft(content="## Summary\n...", title="PR: Add auth", app="github", mcp="github:create_pull_request")
review_draft(content="Bug description...", title="Login bug", app="linear", mcp="linear:create_issue")
review_draft(content="Hello team...", title="Release announcement", app="slack")
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The full draft text to review | |
| title | Yes | Short description of what this draft is | |
| format | No | Content format: md, html, or plain | md |
| app | No | Target app for UI context hints | generic |
| mcp | No | MCP tool to call next if approved (e.g. 'github:create_pull_request') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds crucial behavioral details: 'Opens a browser window with an editor and live preview. Blocks until the user approves or rejects.' This discloses the interactive nature and UI behavior. It also explains the consequences of approval/rejection, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise opening sentence, bullet points for outcomes, and clear examples. Every sentence adds value, and the length is appropriate for the complexity of the tool. It is front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the interactive nature of the tool (no output schema), the description thoroughly covers the behavior: opening an editor, blocking for approval/rejection, and next steps. It also mentions clipboard fallback. The description is complete for the tool's complexity and context signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters. The description adds value by providing examples showing how to use the parameters (e.g., app='github', mcp='github:create_pull_request') and context for 'format' and 'app'. This goes beyond the schema's descriptions, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Let the user review and edit a draft before it goes anywhere.' It specifies the action (review and edit) and the resource (draft). There are no sibling tools to differentiate, but the description is specific and includes examples that reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'When creating PR descriptions, Linear tickets, Slack messages, or emails: call this tool first, then use the approved content with the target tool.' It also explains the flow (blocks until approve/reject) and what to do on each outcome, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0review_draftOnly one tool exists, so no risk of confusion between tools.
The single tool name 'review_draft' follows a clear verb_noun pattern, which is consistent within the set.
The server has exactly one tool, which is minimal but appropriate for a focused drafting/review utility. While the count is low, the purpose is narrow enough that it doesn't feel insufficient.
The server fully delivers on its stated purpose: providing a review step for drafts before sending to other tools. No additional tools are needed for this specific function.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Versioned artifact review for people and AI agents, with contextual comments and human control.
Marketing autopilot in your IDE. AI turns codebase and context into content for 10+ platforms
Your AI's work, reviewed by your team, remembered - shared artifacts with review, plus team memory.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sgasser/draft-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
