Click on "Deploy 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., "@Codemend MCP Server List the latest production errors and suggest a fix for the first one"
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.
Connect Claude Code (and any MCP-compatible AI tool) directly to your Codemend production error monitoring.
With this MCP server, you can ask Claude things like:
"What production errors broke overnight?"
"Get me the fix for error abc123"
"Open a GitHub PR with the AI fix for that login crash"
"Give me the copy-paste prompt so I can paste it into Lovable"
npm install -g codemend-mcpnpx codemend-mcpRelated MCP server: GlitchTip MCP Server
Go to codemend.ai/settings
Generate an API key (starts with ah_)
Add this to your Claude Code MCP configuration (~/.claude/claude_desktop_config.json or your project's .mcp.json):
{
"mcpServers": {
"codemend": {
"type": "stdio",
"command": "npx",
"args": ["-y", "codemend-mcp"],
"env": {
"CODEMEND_API_KEY": "ah_your_key_here"
}
}
}
}Or, if you installed globally:
{
"mcpServers": {
"codemend": {
"type": "stdio",
"command": "codemend-mcp",
"env": {
"CODEMEND_API_KEY": "ah_your_key_here"
}
}
}
}codemend_list_errorsList recent production errors from your Codemend project.
Parameters:
limit (optional, number, 1–50, default 10) — how many errors to return
status (optional, string) — filter by status: "new" | "analyzing" | "analyzed" | "fixed" | "ignored"
Example prompts:
"Show me my 20 most recent production errors"
"List all new errors from Codemend"
"What unresolved errors do I have?"
codemend_get_fixGet the full AI-generated fix for a specific production error, including explanation, root cause, confidence score, suggested code diff, and the fix prompt.
Parameters:
error_id (required, string) — the error ID
Example prompts:
"Get the AI fix for error abc123"
"What does Codemend suggest for fixing error xyz789?"
"Show me the suggested diff for that login crash"
codemend_apply_fixCreate a GitHub PR with the AI-generated fix for an error. Codemend will open a pull request directly in your repo.
Parameters:
fix_id (required, string) — the fix ID to apply
Example prompts:
"Apply the fix for error abc123 and open a PR"
"Create a GitHub PR with the Codemend fix"
codemend_copy_fixGet the copy-paste fix prompt for an error — ideal for vibe coders using Lovable, Replit, v0, Cursor, Bolt, or any AI coding platform. Returns the ready-to-paste prompt plus a plain-English explanation.
Parameters:
error_id (required, string) — the error ID
Example prompts:
"Give me the copy-paste fix prompt for error abc123"
"I want to paste the fix into Lovable — what's the prompt?"
"Get me the vibe-coder fix for that checkout crash"
codemend_project_healthCheck the health and status of your Codemend monitoring setup — project name, errors this month, quota usage, last error time, and monitoring status.
Parameters: none
Example prompts:
"How is my Codemend monitoring doing?"
"Check my error quota"
"Is Codemend still receiving errors?"
Variable | Description |
| Your Codemend API key (required) |
| Override API base URL (default: |
You can also pass the API key as a CLI flag:
codemend-mcp --api-key ah_your_key_here# Clone the repo
git clone https://github.com/hankmint/codemend-ai
cd codemend-ai/packages/codemend-mcp
# Install deps & build
npm install
npm run build
# Test with your API key
CODEMEND_API_KEY=ah_your_key node dist/index.jsMIT — Knod, Inc.
Create a GitHub PR with the AI-generated fix for an error
| Name | Required | Description | Default |
|---|---|---|---|
| fix_id | Yes | The fix ID to apply (creates a GitHub PR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It states the primary action (creates a PR) but omits critical behavioral details: authentication requirements, idempotency (what happens if run twice), whether it pushes a branch, or what success/failure looks like.
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?
Single front-loaded sentence with zero redundancy. Appropriate length for a single-parameter tool; every word serves a 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 low complexity (1 param, no nested objects), the description adequately covers the core action. However, lacking an output schema, it should ideally mention what the tool returns (e.g., PR URL/number) or link to the sibling workflow, warranting a middle score.
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 has 100% description coverage ('The fix ID to apply'), establishing baseline 3. Description adds context that the fix is 'AI-generated' and for 'an error', slightly enriching semantics, but does not clarify the fix_id's origin or format beyond the schema.
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?
Clear verb ('Create') and resource ('GitHub PR') with context ('AI-generated fix for an error'). However, it does not explicitly differentiate from siblings like 'codemend_copy_fix' or 'codemend_get_fix', leaving ambiguity about when to apply versus copy.
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?
No explicit guidance on when to use this tool versus alternatives (copy_fix vs apply_fix), prerequisites for the fix_id, or workflow sequencing with codemend_list_errors/get_fix. Usage must be inferred from the action description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the copy-paste fix prompt for an error (for vibe coders using Lovable, Replit, v0, Cursor, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| error_id | Yes | The error ID to retrieve the fix prompt for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It successfully indicates the tool returns a text prompt for manual use, but fails to disclose safety properties (read-only vs destructive), error handling for invalid error_id, or rate limits.
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?
Single sentence with zero waste. Front-loaded action ('Get'), followed by resource definition, with parenthetical context efficiently appended. Every clause earns its place.
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?
For a simple single-parameter retrieval tool without output schema, the description adequately explains what is returned (a copy-paste prompt). Could improve by explicitly stating the return format (string/text) since no output schema exists to document this.
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?
Input schema has 100% description coverage for error_id. Description does not add parameter-specific details (examples, formats), so baseline score of 3 is appropriate as the schema carries the full semantic load.
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?
Description uses specific verb 'Get' with resource 'copy-paste fix prompt' and clearly distinguishes from sibling 'codemend_get_fix' by emphasizing the prompt format for manual copying, and from 'codemend_apply_fix' by implying a manual workflow.
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?
Provides clear contextual guidance by specifying target users ('vibe coders') and specific tools ('Lovable, Replit, v0, Cursor'), indicating when to use this tool. However, lacks explicit 'when-not-to-use' or direct comparison to siblings like codemend_get_fix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the AI-generated fix for a specific production error
| Name | Required | Description | Default |
|---|---|---|---|
| error_id | Yes | The error ID to retrieve the fix for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure but fails to specify whether the fix is retrieved from cache or generated on-demand, what format the fix is returned in, error handling for invalid IDs, or idempotency characteristics.
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?
Extremely concise at 9 words in a single sentence. Front-loaded with action verb. However, the brevity comes at the cost of missing behavioral and workflow context that would be valuable for an agent determining tool selection.
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?
For a single-parameter tool with complete schema coverage, the description is minimally adequate. However, given no output schema and no annotations, it lacks information about the return structure (code snippet, patch, or explanation) and doesn't clarify the relationship to the fix application workflow.
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% with the error_id parameter fully documented as 'The error ID to retrieve the fix for'. The description doesn't add additional semantic context about the parameter format or constraints, but the schema is sufficient, meeting the baseline expectation.
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?
States specific action ('Get') and resource ('AI-generated fix') with clear scope ('for a specific production error'). However, it doesn't explicitly differentiate from siblings like codemend_copy_fix or codemend_apply_fix which are related operations in the same workflow.
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?
Provides no guidance on when to use this tool versus alternatives. Doesn't mention the likely workflow (e.g., use after list_errors, before apply_fix) or prerequisites like requiring a valid error_id from the list_errors tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent production errors from your Codemend project
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of errors to return (1–50, default 10) | |
| status | No | Filter by status: "new" | "analyzing" | "analyzed" | "fixed" | "ignored" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'recent' (temporal scope) and 'production' (environment), but lacks critical disclosure needed given zero annotations: no safety profile confirmation (read-only vs destructive), no clarification of 'recent' timeframe, no return value description, and no rate limit or auth context.
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?
Single sentence, front-loaded with action verb, zero redundancy. However, given lack of annotations and output schema, the extreme brevity borders on under-specification rather than optimal conciseness.
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?
Sufficient for a simple list operation with optional filters, but misses opportunity to clarify relationship to fix-related siblings or hint at return structure (error IDs vs full objects) given no output schema exists.
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% with complete descriptions for 'limit' and 'status' parameters. Description adds no parameter details, which is acceptable when schema is fully self-documenting. Baseline 3 appropriate.
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?
Clear verb 'List' + specific resource 'production errors' + scope 'from your Codemend project'. Distinct from siblings which focus on fixes (apply_fix, get_fix) or aggregate health (project_health).
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?
Usage is implied by the verb 'List' versus sibling tools that manipulate fixes, but no explicit when-to-use guidance or workflow sequence (e.g., 'use this before applying fixes') is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health and status of your Codemend monitoring setup
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to specify what health metrics are verified (connectivity, configuration, permissions), the return format, or whether the operation is read-only.
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 consists of a single, efficient 9-word sentence that front-loads the action verb. There is no redundant or wasted text given the simplicity of the tool.
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?
While appropriately brief for a zero-parameter tool, the description lacks information about return values or output structure in the absence of an output schema. It adequately conveys the high-level purpose but leaves operational specifics undocumented.
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?
The tool accepts zero parameters, establishing a baseline of 4. With no arguments to document and 100% schema coverage trivially satisfied, no additional parameter semantics are required from the description.
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 uses a clear specific verb ('Check') and identifies the resource ('health and status of your Codemend monitoring setup'). It implicitly distinguishes from fix-oriented siblings (apply_fix, copy_fix, etc.) by focusing on health/status rather than remediation.
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 provides no guidance on when to invoke this tool versus alternatives. It does not indicate whether this should be called before error remediation, how often to poll it, or what constitutes a healthy versus unhealthy state.
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.
v0.1.0codemend_apply_fixcodemend_copy_fixcodemend_get_fixcodemend_list_errorscodemend_project_healthScored across 5 tools
The three fix-related tools (get_fix, copy_fix, apply_fix) serve distinct purposes—retrieving the fix, formatting it for copy-paste, and creating a PR—but their similar names could cause temporary hesitation. list_errors and project_health are clearly distinct from the fix workflow.
Four tools follow a consistent verb_noun pattern (apply_fix, copy_fix, get_fix, list_errors), but codemend_project_health breaks this convention by using a noun_noun structure instead of a verb like check_health or get_status. The prefixing is uniform, making the set mostly predictable.
Five tools strike an appropriate balance for this focused error-monitoring domain, covering error discovery, fix retrieval in two formats, automated application, and health monitoring without bloat. The scope is well-defined and each tool earns its place.
The set covers the core lifecycle of identifying production errors and retrieving or applying AI-generated fixes via multiple workflows (manual copy-paste or automated PR). Minor gaps exist in error lifecycle management, such as marking errors as resolved or ignored, but the primary fix-oriented workflow is fully supported.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Give AI coding agents access to your Vynix visual feedback, bug reports, and AI diagnosis.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
AI-powered intelligence for your development workflow via Indicate.
