CodeRecoder MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is overlap between legacy tools (record_edit, rollback_to_version, list_history) and their faster counterparts (create_file_snapshot, restore_file_snapshot, list_file_snapshots). The descriptions explicitly mark legacy tools and point to alternatives, reducing confusion, but the redundancy still creates potential for misselection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_current_session, create_file_snapshot, list_projects). Variations like rollback_to_version still fit the verb-based pattern, making the naming predictable and easy to navigate.
Tool Count4/5
17 tools is slightly above the ideal 3-15 range but reasonable for the scope covering sessions, projects, file snapshots, and project snapshots. The count is inflated by three legacy tools that duplicate functionality; removing them would bring it to a more optimal 14 tools.
Completeness4/5
Core workflows for snapshots (create, list, restore, delete) and project management are covered, along with session and diff utilities. Minor gaps exist, such as the lack of a delete_project_snapshot operation and no way to get details of a single file snapshot beyond the list, but agents can still accomplish primary tasks.
Average 3.6/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions analyzing changes via 'Serena' and saving incrementally/fully based on 'save count', but these are vague and undefined. It does not disclose side effects, permissions, or return behavior, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. However, the second sentence introduces ambiguous terms ('Serena', 'save count') that reduce clarity. Still, it is concise without excessive wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what happens after creation, what 'save count' means, who Serena is, or whether existing snapshots are affected. The complexity of a project snapshot tool demands more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides; it only references an unrelated 'save count' concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a project-wide snapshot creation with the verb 'Create' and resource 'project-wide snapshot'. The 'like Cursor' analogy helps, and 'project-wide' distinguishes it from sibling create_file_snapshot, giving it a specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_file_snapshot or other alternatives. The description implies project-level snapshots but does not mention exclusions or alternative tools. 'Like Cursor' is an analogy, not a usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions potential behavior ('current active project') but fails to disclose what 'detailed information' includes, whether the operation is read-only, or any potential side effects. This lack of behavioral detail is a gap for a tool dealing with project data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the essential purpose. Every word contributes meaning, with no redundancy or filler. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter), but there is no output schema, and the description does not specify what information is returned. The context is incomplete for an AI agent trying to understand what 'detailed information' means or how to interpret the result. More detail on return value would be needed for full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description fully covers the single parameter 'projectPath', including the optional behavior when omitted. The tool description only restates this with slightly different wording ('current active project' vs 'current project'), adding no meaningful extra meaning. With 100% schema coverage, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving detailed project information, with an option to target the current active project. It is specific about the action ('get') and resource ('project'), though it does not explicitly differentiate from sibling tools like 'get_current_session' or 'list_projects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need project details, and specifically mentions the behavior when no path is given (returns current project). However, it does not provide explicit guidance on when to use it over alternatives, such as using 'get_current_session' for session-level info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It only says 'Record a code edit for version history tracking,' but does not explain what recording entails (e.g., whether it writes to a persistent store, whether it modifies files, or if any permissions are needed). This is a significant gap for a tool that likely has mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences to convey the legacy status and a performance comparison. It is front-loaded with the 'Legacy' warning. However, it may be too brief for a tool with eight parameters, lacking necessary elaboration for safe use, but the conciseness itself is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has eight parameters and no output schema, the description is incomplete. It does not explain the tool's behavior beyond recording an edit, nor does it mention any prerequisites, side effects, or edge cases. The 'Legacy' note is helpful but not sufficient for full contextual understanding, leaving significant gaps for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all eight parameters having explicit descriptions in the schema. The tool description adds no parameter-specific information, so it does not enhance the semantic understanding beyond the schema. Baseline of 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Record a code edit') and its purpose ('for version history tracking'). While it doesn't explicitly differentiate from all sibling tools, the 'Legacy' label and the note about create_file_snapshot provide some distinction, making the purpose understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance by labeling the tool as 'Legacy' and explicitly noting that 'create_file_snapshot is much faster.' This implies prefer the alternative while still allowing this tool for older workflows, giving a concrete comparison and implicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, but it only states 'deactivate' and 'optionally save history'. It does not explain what deactivation entails (e.g., closing a session, irreversibility, impact on current state) or what happens to history when saveHistory is false. This is insufficient for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It communicates the core action and the optional parameter efficiently, earning its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature and lack of annotations/output schema, the description is too sparse. It does not explain the practical implications of deactivation, whether it is reversible, how it interacts with the current session, or why saveHistory might be necessary. The presence of activate_project as a sibling only implies the inverse, but the tool still needs more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for saveHistory ('Whether to save current history before deactivating'), and schema coverage is 100%. The tool description's mention of 'optionally save history' paraphrases the schema without adding new meaning, so it does not elevate beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'deactivate' and identifies the resource 'current project', clearly distinguishing it from siblings like activate_project. It also mentions the optional saveHistory behavior, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (deactivate the current project) but does not explicitly state when to use it versus alternatives such as activate_project or snapshot tools. There is no mention of prerequisites, such as requiring an active session, or when one might choose not to save history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get information' but does not explicitly state that this is a read-only operation, nor does it describe what happens if no active session exists, whether errors are returned, or what the response format 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It front-loads the verb and resource, making it immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters, but there is no output schema and the description does not explain what 'information' is returned. In the context of sibling tools, an agent might need to know whether this returns session ID, timestamps, or status, which is missing. However, the core purpose is clear enough for basic selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema fully covers this aspect. The baseline of 4 applies because there is nothing to explain beyond the absence of parameters; the description adds no parameter-specific semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('current active session'). It distinguishes itself from sibling tools like create_session or list_history by focusing on the current session rather than creating or listing history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this should be used to retrieve current session info instead of other session-related tools, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'List' implies a read-only operation, the description does not explicitly state that it is non-destructive, nor does it clarify the scope of 'all project snapshots' (e.g., current project vs. all projects). It also lacks any mention of side effects, permissions, or context requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core purpose and expected output. There is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no required parameters and no output schema. The description lists the output fields, which is helpful, but it leaves ambiguity about the project scope and does not explain what 'Serena analysis' entails. These gaps make it incomplete for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the single 'format' parameter is fully described). The description adds no extra meaning to the parameter itself, but the baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List'), resource ('project snapshots'), and the key output fields ('save numbers, types (incremental/full), and Serena analysis'). This distinguishes it from sibling tools like list_file_snapshots or create_project_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to list project snapshots) but does not explicitly differentiate from alternative tools such as list_file_snapshots or provide when-not-to-use guidance. The context is clear from the name and sibling list, but no explicit exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 disclosing behavioral traits. It mentions 'instant' and 'direct file copying', but critically omits that restoring may overwrite the current file or be irreversible. For a state-modifying operation, this lack of safety/effect disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero redundancy. The first sentence states the action, and the second adds a meaningful detail about the method. The description is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the core operation is described, but the description does not explain return values, potential side effects (e.g., overwriting the file), or prerequisites (snapshot must exist). Given no output schema and no annotations, this is only minimally complete for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description for the only parameter ('Snapshot ID to restore from'). The tool-level description adds no additional parameter semantics, but with 100% schema coverage the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Restore') and specific resource ('a file from a snapshot'), distinguishing it from project-snapshot restore. The phrase 'Instant file restore using direct file copying' adds a concrete behavioral detail that reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied (use this tool to restore a file) but no explicit when-to-use or when-not-to-use guidance is given. The description does not mention alternatives like 'rollback_to_version' or 'restore_project_snapshot', leaving it to inference from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must disclose behavioral traits. It only says 'Restore entire project,' which implies overwriting but does not mention irreversible changes, required permissions, or whether the restore can be undone. This insufficient disclosure for a mutation tool merits a 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words: 'Restore entire project to a specific snapshot state.' It is front-loaded and contains no fluff, achieving a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description is minimal. However, as a project-level mutation, it lacks context about consequences, such as whether current changes are lost or if it creates a new history entry. This is a gap, but the simplicity of the tool keeps it at a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a 100% description of the single parameter snapshotId. The description adds no new information beyond what the schema already says, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states, 'Restore entire project to a specific snapshot state.' The verb 'Restore' is specific, and 'entire project' clearly scopes the operation to project-level, distinguishing it from sibling restore_file_snapshot. This matches a 5 for purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool versus restore_file_snapshot or rollback_to_version. It only implies project-level use via 'entire project,' but lacks explicit alternatives or exclusions. This is implied usage, so a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'direct file copying' which implies the original file is preserved, and notes speed as a benefit. However, without annotations, it fails to disclose other behavioral aspects such as permissions, storage location, overwrite behavior, or error conditions, leaving ambiguity about the snapshot's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately state the purpose and a distinguishing advantage. Every word adds value, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema covers all parameters, the description omits critical information about return values (e.g., snapshot ID), storage of snapshots, error handling, and integration with sibling tools like restore_file_snapshot. Without annotations or an output schema, this leaves the tool incompletely specified for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema (100% coverage), including prompt, filePath, metadata, and sessionId. The description adds no additional parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a file snapshot for backup and restore, and explicitly distinguishes it from record_edit by noting it's faster and uses direct file copying. This specific verb and resource combination makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context by comparing to record_edit, indicating this tool is a faster alternative for creating backups. However, it does not explicitly mention when not to use it or enumerate other alternatives like restore_file_snapshot, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that a diff is generated, implying a read-only operation, but does not explicitly confirm non-destructiveness, mention any permissions, describe the output format, or note edge cases. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. It is front-loaded with the action and resource, with no filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, both fully documented in the schema, and no output schema. The description sufficiently explains the core functionality for a diff tool. However, it does not mention the return value or any limitations (e.g., only works within the same session), which could be considered a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters, with each having a clear description ('ID of the first edit' and 'ID of the second edit'). The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Generate a diff' with a clear resource ('two edit versions') and states the purpose ('to see what changed'). This clearly distinguishes it from sibling tools like rollback_to_version or restore_file_snapshot, which perform state changes rather than comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing edit versions but does not explicitly state when to use this tool over alternatives or provide any exclusion criteria. The purpose makes it obvious for diff scenarios, but there is no context about prerequisites or what distinguishes it from related list/history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions legacy status and speed comparison. It does not explain side effects, whether the operation is destructive, permissions required, or what happens to current files, leaving significant behavioral ambiguity for a rollback operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise at two sentences, with the 'Legacy' warning and alternative reference each earning their place. Information is front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple two-parameter schema, this is a mutation tool with no output schema and no annotation support. The description fails to convey behavioral impact, return values, or prerequisites, leaving the overall context incomplete for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both sessionId and editId already described meaningfully in the schema. The tool description adds no additional parameter context, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Rollback' with a clear resource 'files to a previous version,' making the tool's function immediately understandable. It also distinguishes itself from siblings by labeling it 'Legacy' and explicitly referencing the faster alternative 'restore_file_snapshot.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by marking the tool as 'Legacy' and noting that 'restore_file_snapshot is much faster,' which steers users toward the alternative. However, it does not explicitly state any exclusions or specific scenarios where rollback_to_version should still be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does mention the main side effect (creating a cache directory), but it omits details such as idempotency, permissions required, error behavior if the project is already active, or whether existing data is overwritten. This is a moderate level of transparency given the mutation nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb, resource, and effect without any filler. It earns its place and is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is moderately adequate. It explains the core functionality but fails to mention return values, preconditions, or failure scenarios. Given the tool's simplicity and full schema coverage, it's minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the description doesn't need to add param details. However, the description also adds no extra meaning about how language or projectName affect the behavior, staying at the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activate a project') and its purpose ('for code tracking'), and it specifies the tangible effect ('Creates .CodeRecoder cache directory with structured data'). This distinguishes it from sibling tools like deactivate_project or snapshot tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to start code tracking for a project, but it provides no explicit when-to-use or when-not-to-use guidance. It doesn't contrast with alternatives like create_session or create_project_snapshot, so the usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention any prerequisites, side effects, or relationship with other session tools like get_current_session or record_edit, only stating its purpose. This leaves the agent unaware of what creation entails beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first sentence stating the primary action and the second giving a use case. There is no redundant information, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema, so the description only needs to convey the core purpose and context. It does that, though it omits details about return values and how the session connects to other editing tools. For a straightforward creation tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters (name and description) with their own descriptions, so the description adds no additional parameter semantics. Baseline 3 is appropriate since schema coverage is 100%, and the description's purpose statement implicitly relates to the session's identity but does not elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new editing session to group related changes,' which is a specific verb and resource. It distinguishes itself from siblings like get_current_session or create_file_snapshot by referring to an 'editing session' rather than a retrieval or snapshot operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is 'Useful for organizing different features or experiments,' providing a clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, such as when you need file snapshots instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states that the operation 'cannot be undone' and that it deletes 'associated files,' which is important destructive-behavior context. However, it does not mention permissions, side effects on history, or whether the deletion is permanent across sessions, so it falls short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both essential. The first sentence states the action and scope, the second adds an important warning. It is succinct and well-structured, with no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description covers the core purpose, the scope (including associated files), and the irreversible nature. It is reasonably complete, though it could benefit from mentioning permission requirements or the effect on related snapshots. Given the tool's simplicity, the description is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes snapshotId as 'ID of the snapshot to delete,' providing 100% coverage. The description does not add any semantic detail beyond the schema, simply referring to 'a specific file snapshot.' With full schema coverage, the baseline is 3, and no extra context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and identifies the exact resource ('a specific file snapshot and its associated files'). This clearly distinguishes it from sibling tools like restore_file_snapshot, create_file_snapshot, and list_file_snapshots, which have different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It includes a caution about irreversibility but does not mention any conditions for use or suggest an alternative (e.g., restore_file_snapshot) for recovering deleted content. There is no explicit 'when to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the extra behavior of showing the active project but does not explicitly state that it is read-only, nor does it mention any permissions or side effects. The verb 'list' implies safety, but explicit disclosure is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, front-loaded with the action and object. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description gives a reasonable hint of the output: a list of available projects and the current active project. It does not specify ordering or pagination, but these are not expected for such a lightweight listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100%. The baseline for zero parameters is 4, and the description does not need to add parameter details. Nothing is missing here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' with a clear resource 'projects' and also mentions showing the current active project, which adds precision. It distinguishes itself from mutations like activate_project/deactivate_project by focusing on read-only listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_project_info or list_project_snapshots. The description does not mention any exclusions or context where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It adds the legacy status and performance comparison, which is useful context. However, it does not specify whether the operation is read-only, what it returns, or any error or authorization details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys all necessary information without redundancy. The note about the faster sibling is valuable and succinctly placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three optional parameters and no output schema, the description gives the core purpose and an important performance caveat. It lacks details on return value structure, pagination behavior, or legacy-specific caveats, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have full schema descriptions (limit, filePath, sessionId), so the schema already covers semantics. The description adds no additional parameter-specific guidance, keeping this at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('List edit history'), its purpose ('for debugging'), and its legacy status. It also distinguishes itself from the sibling tool by noting that list_file_snapshots is much faster, effectively differentiating it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear alternative ('list_file_snapshots is much faster') and implies that this tool is for debugging scenarios. It does not explicitly say when not to use it, but the legacy label and performance note offer practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool shows snapshot time, modified files, and AI summaries, but does not explicitly state it is read-only or describe any side effects. The verb 'list' implicitly signals a safe operation, but additional behavioral detail (e.g., no modifications, return format) would strengthen transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and key differentiators (AI-enhanced, easy rollback selection). It adds relevant detail without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately covers the core behavior and the content of the returned data. It could mention the default limit or the availability of filters, but those are already in the schema, so the description is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all four parameters (limit, format, filePath, sessionId), so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('List AI-enhanced file snapshots') and adds purpose context ('for easy rollback selection'). It clearly distinguishes from sibling tools like list_project_snapshots and restore_file_snapshot by focusing on the listing behavior for file snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when you need to select a file snapshot for rollback. It does not explicitly name alternatives or exclusions, but the context of 'rollback selection' is concrete enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![CodeRecoder MCP server](https://glama.ai/mcp/servers/snow-wind-001/CodeRecoder/badges/card.svg)](https://glama.ai/mcp/servers/snow-wind-001/CodeRecoder)

Score Badge

Copy to your README.md:

[![CodeRecoder MCP server](https://glama.ai/mcp/servers/snow-wind-001/CodeRecoder/badges/score.svg)](https://glama.ai/mcp/servers/snow-wind-001/CodeRecoder)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/snow-wind-001/CodeRecoder'

If you have feedback or need assistance with the MCP directory API, please join our Discord server