SVN MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Each targets a specific SVN operation (e.g., checkout, commit, diff, log) with clear boundaries between them. The descriptions reinforce distinct functions, making misselection unlikely.
Naming Consistency5/5
All tools follow a consistent 'svn_verb' or 'svn_noun_verb' pattern (e.g., svn_checkout, svn_commit, svn_health_check). The naming is uniform throughout, using snake_case and starting with 'svn_' as a prefix, making it predictable and readable.
Tool Count5/5
With 14 tools, the count is well-scoped for an SVN server, covering core operations like version control, file management, diagnostics, and history. Each tool earns its place without feeling excessive or insufficient for the domain.
Completeness5/5
The tool set provides complete coverage of essential SVN workflows, including CRUD operations (add, delete, commit, revert), repository interactions (checkout, update), diagnostics (health_check, diagnose), and history/logging. No obvious gaps exist for typical agent tasks.
Average 2.9/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 the full burden of behavioral disclosure. It mentions cleaning interrupted operations but doesn't detail what this entails (e.g., whether it's destructive, requires specific permissions, or has side effects like removing temporary files). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, though it could benefit from slightly more detail given the lack of annotations and output schema.
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 complexity (a mutation operation for cleaning interrupted SVN operations), the absence of annotations and output schema, and the description's limited behavioral details, the description is incomplete. It doesn't explain what 'cleaning' entails, potential impacts, or return values, leaving the agent with insufficient context for safe and effective use.
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 has 1 parameter with 100% description coverage ('Ruta específica a limpiar'), so the schema already documents the parameter meaning. The description adds no additional semantic context beyond what the schema provides, resulting in a baseline score of 3 as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('Limpiar working copy de operaciones interrumpidas') which translates to 'Clean working copy of interrupted operations', providing a specific verb ('clean') and resource ('working copy'). However, it doesn't clearly distinguish from siblings like 'svn_revert' or 'svn_status' which might handle similar cleanup scenarios, leaving the differentiation vague.
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 alternatives like 'svn_revert' or 'svn_status' is provided. The description implies usage for interrupted operations but doesn't specify contexts, exclusions, or prerequisites, offering minimal direction for selection among sibling 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 full burden but only states it diagnoses problems without detailing behavioral traits like what it inspects (e.g., logs, configurations), whether it's safe or destructive, or what output to expect. It adds minimal context beyond the basic purpose.
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 a single, concise sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized for a no-parameter tool, though it could be more front-loaded with specifics.
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?
For a diagnostic tool with no annotations, no output schema, and 0 parameters, the description is incomplete. It doesn't explain what problems it diagnoses, how it works, or what results to expect, leaving significant gaps for an AI agent to understand its use.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Diagnosticar problemas específicos con comandos SVN' states a general purpose (diagnose SVN command problems) but lacks specificity about what kind of problems or how it differs from sibling tools like 'svn_health_check'. It's not tautological but remains vague about the exact 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 guidance is provided on when to use this tool versus alternatives like 'svn_health_check' or other diagnostic methods. The description implies usage for SVN command issues but doesn't specify contexts, prerequisites, or exclusions.
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 behavioral disclosure. It states the action ('añadir') but doesn't explain what this entails (e.g., files become tracked, changes are staged for commit), potential side effects (e.g., file locking, repository updates), or constraints (e.g., permissions, network requirements). This is a significant gap for a mutation 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, efficient sentence in Spanish ('Añadir archivos al control de versiones') that directly states the tool's purpose. It is front-loaded with no wasted words, making it highly concise and well-structured for quick understanding.
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 complexity (a mutation tool with 6 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or output expectations, leaving gaps that could hinder an agent's ability to invoke the tool correctly in a real-world scenario.
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%, meaning all parameters are documented in the schema. The description adds no additional meaning about parameters beyond what the schema provides (e.g., it doesn't clarify interactions like 'autoProps' vs 'noAutoProps'). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate or add value.
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 'Añadir archivos al control de versiones' clearly states the verb ('añadir') and resource ('archivos al control de versiones'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like 'svn_commit' or 'svn_update', which also involve version control operations, so it lacks sibling distinction.
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 doesn't mention prerequisites (e.g., files must be untracked), contrast with siblings (e.g., 'svn_commit' for saving changes), or specify contexts (e.g., initial file addition). This leaves the agent without usage direction.
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 but offers minimal information. It states the action (checkout) but doesn't describe what the tool actually does (e.g., creates a working copy, downloads files, requires authentication, handles errors, or returns output). This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 complexity (6 parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain what the tool returns, error conditions, authentication needs, or how it interacts with the filesystem. For a tool that performs a significant filesystem operation like checkout, more context is needed.
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%, with all 6 parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for adequate coverage when the schema does the heavy lifting.
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 'Hacer checkout de un repositorio SVN' clearly states the action (checkout) and resource (SVN repository) in Spanish. It distinguishes this tool from siblings like svn_commit or svn_update by specifying the checkout operation, though it doesn't explicitly contrast with similar tools like svn_update that also retrieve files.
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 doesn't mention prerequisites (e.g., needing an SVN repository URL), when not to use it (e.g., for updating existing checkouts), or refer to sibling tools like svn_update for different scenarios.
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 states the action ('confirmar cambios') but doesn't reveal critical traits: whether this is a destructive operation (likely yes, as commits are permanent), authentication requirements, rate limits, or what happens on success/failure (e.g., returns a commit hash). For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient phrase ('Confirmar cambios al repositorio') that front-loads the core purpose without unnecessary words. It's appropriately sized for a tool with a clear primary function, and every part of the sentence earns its place by specifying the action and target.
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 complexity (6 parameters, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects (e.g., destructiveness, auth needs), output expectations, or error handling. For a commit tool in a version control context, this leaves critical gaps for an AI agent to use it effectively.
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 parameters well-documented in the schema (e.g., 'message' as commit message, 'paths' as specific files). The description adds no parameter semantics beyond what the schema provides—it doesn't explain parameter interactions (e.g., 'message' vs. 'file') or usage nuances. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with extra context.
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 'Confirmar cambios al repositorio' clearly states the verb ('confirmar') and resource ('repositorio'), translating to 'commit changes to the repository' in English. It distinguishes from siblings like svn_add or svn_revert by focusing on committing rather than adding or reverting changes. However, it doesn't explicitly differentiate from all siblings (e.g., svn_update also modifies the repository), so it's not a perfect 5.
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 doesn't mention prerequisites (e.g., needing staged changes), exclusions (e.g., not for uncommitted files), or comparisons to siblings like svn_add (for adding files) or svn_revert (for undoing changes). This leaves the agent with minimal context for tool selection.
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 behavioral disclosure. While 'Eliminar' implies a destructive operation, it doesn't specify critical details like whether this requires commit permissions, if deletions are permanent or reversible, what happens to file history, or any rate limits. For a destructive tool with zero annotation coverage, this is a significant gap in 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 a single, clear sentence in Spanish that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to understand at a glance, which is ideal for conciseness.
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 complexity (a destructive operation with 4 parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, permissions, or output format, which are crucial for proper use. While the schema handles parameters well, the overall context for a deletion tool is insufficient.
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%, meaning all parameters are documented in the schema itself (e.g., 'paths' for files/directories to delete, 'message' for commit message, 'force' to force deletion, 'keepLocal' to keep local copies). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high coverage.
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 action ('Eliminar' meaning 'Delete') and the target ('archivos del control de versiones' meaning 'files from version control'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'svn_revert' or 'svn_cleanup', which might also involve removal operations in different contexts.
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. For example, it doesn't clarify if this is for deleting files from the repository permanently versus local cleanup, or how it differs from 'svn_revert' (which undoes changes) or 'svn_cleanup' (which cleans up working copy issues). Without such context, users might misuse it.
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 full burden for behavioral disclosure. While 'Ver diferencias' implies a read-only operation, it doesn't specify whether this requires authentication, what format the diff output takes (unified diff, side-by-side, etc.), whether it shows changes for entire directories or just files, or any rate limits. The description is too minimal for a tool with behavioral implications.
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, efficient sentence in Spanish that directly states the tool's purpose. There's no wasted language or unnecessary elaboration - every word contributes to understanding what the tool does.
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?
For a version control diff tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the output looks like (text diff format), whether it handles binary files, what happens when revisions aren't specified, or any error conditions. The minimal description leaves too many behavioral questions unanswered.
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%, with all three parameters ('path', 'oldRevision', 'newRevision') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline for when schema coverage is high.
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 verb ('Ver diferencias' - View differences) and resource ('entre versiones de archivos' - between file versions), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'svn_log' or 'svn_status' which might also show version information, but the core function is well-defined.
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 doesn't mention when this tool is appropriate compared to 'svn_log' (which shows commit history) or 'svn_status' (which shows working copy status), nor does it specify any prerequisites or constraints for usage.
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 behavioral disclosure. It states this is an information retrieval operation ('obtener información'), which implies it's likely read-only, but doesn't confirm this or describe any other behavioral traits like error handling, output format, or performance characteristics. This leaves significant gaps for a tool with no 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, efficient sentence in Spanish that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of SVN operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'información detallada' includes, how results are structured, or any prerequisites (e.g., requires an SVN working copy). For a tool in a domain with many siblings, this leaves too much ambiguity.
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%, with the single parameter 'path' documented as an optional string for a specific route to query. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.
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 verb ('obtener información detallada') and resource ('working copy o archivo específico'), making the purpose understandable. However, it doesn't explicitly differentiate this from sibling tools like 'svn_status' or 'svn_log' which might also provide information about SVN repositories, missing full sibling distinction.
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. With siblings like 'svn_status' and 'svn_log' that might offer different types of information, the description lacks any context about when this specific info retrieval is appropriate, leaving the agent to guess based on tool names alone.
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 behavioral disclosure. While 'ver historial' implies a read-only operation, the description doesn't disclose important behavioral aspects like whether this requires authentication, what format the output takes, whether it shows all branches or just trunk, or any rate limits. For a tool with 3 parameters and no annotation coverage, this is insufficient.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a straightforward tool and front-loads the core functionality. Every word earns its place.
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 that this is a 3-parameter tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the output looks like (list of commits? detailed information per commit?), doesn't mention authentication requirements, and provides no context about typical use cases. For a tool that likely returns structured historical data, more completeness is needed.
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?
With 100% schema description coverage, all parameters are already documented in the input schema. The description doesn't add any additional semantic context about the parameters beyond what's in the schema descriptions. The baseline score of 3 is appropriate since the schema does the heavy lifting, but the description doesn't enhance understanding of how parameters interact or typical usage patterns.
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 'Ver historial de commits del repositorio' clearly states the tool's purpose as viewing commit history in a repository. It uses a specific verb ('ver' - view) and resource ('historial de commits'), but doesn't differentiate from sibling tools like 'svn_info' which might also provide historical information. The description is in Spanish, which matches the parameter descriptions.
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. With multiple sibling tools like 'svn_info', 'svn_status', and 'svn_diff' that might provide related information, there's no indication of when this specific log viewing tool is appropriate versus other options.
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 full burden for behavioral disclosure. It states the tool reverts local changes but doesn't clarify whether this is destructive (permanently discarding uncommitted work), requires authentication, has side effects on the working copy, or what happens on success/failure. This leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the core functionality.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'revertir' entails behaviorally (e.g., does it restore to last committed state?), potential risks, or expected outcomes, leaving the agent with insufficient context for safe invocation.
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%, with the parameter 'paths' well-documented as 'Archivo(s) o directorio(s) a revertir'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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 action ('Revertir cambios locales') and target ('en archivos'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'svn_cleanup' or 'svn_update' which might also affect local changes, missing full sibling differentiation.
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 like 'svn_cleanup' (which might handle local issues differently) or 'svn_update' (which might fetch remote changes). There's no mention of prerequisites, timing, or exclusions for usage.
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 behavioral disclosure. It states the tool checks file status but doesn't describe what 'estado' entails (e.g., modified, added, conflicted), whether it's read-only or has side effects, or how results are presented. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and safety.
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, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by conveying essential information concisely.
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 complexity (a version control status tool with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the status output includes, potential side effects, or error conditions. For a tool that likely returns detailed file information, more context is needed to use it effectively without trial and error.
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 schema already documents both parameters ('path' and 'showAll') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or contextual usage. Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is added.
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 'Ver el estado de archivos en el working copy' clearly states the tool's purpose: checking the status of files in a working copy. It uses specific verbs ('ver el estado') and identifies the resource ('archivos en el working copy'), which distinguishes it from siblings like svn_commit or svn_update. However, it doesn't explicitly differentiate from all siblings (e.g., svn_info might also provide status-like information), so it doesn't reach the highest score.
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 doesn't mention prerequisites (e.g., needing a working copy), exclusions, or comparisons to siblings like svn_info or svn_diff. Without such context, users must infer usage from the purpose alone, which is insufficient for optimal tool selection.
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 full burden for behavioral disclosure. 'Actualizar working copy' implies a mutation operation that modifies local files, but the description doesn't disclose important behavioral traits: whether this overwrites local changes, requires authentication, has side effects on uncommitted work, or what happens with conflicts. The description is too minimal for a mutation 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, efficient Spanish sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a basic operation and front-loads the core functionality. Every word earns its place in this minimal description.
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?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address the tool's safety profile, conflict resolution behavior, or what happens to local modifications. Given the complexity of SVN update operations and the lack of structured metadata, the description should provide more contextual information about behavioral implications.
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 schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter interactions, default behaviors, or practical usage examples. With complete schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Actualizar' - Update) and target ('working copy desde el repositorio' - working copy from the repository), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'svn_checkout' (which also retrieves from repository) or 'svn_revert' (which also modifies working copy), missing full sibling differentiation.
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 doesn't mention when to choose svn_update over svn_checkout (initial retrieval) or svn_revert (undo changes), nor does it specify prerequisites like requiring an existing working copy. There's only implied usage context from the tool name itself.
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 behavioral disclosure. While it indicates this is a read-only diagnostic operation ('verificar el estado'), it doesn't describe what the health check actually entails, what specific aspects are examined, whether it requires authentication, if it has side effects, or what the output format looks like. For a diagnostic tool with zero annotation coverage, this is insufficient.
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, efficient sentence in Spanish that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a no-parameter diagnostic tool and is completely front-loaded with the essential information.
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 the tool has no parameters and no output schema, the description provides the basic purpose but lacks important context. For a health check tool, users would benefit from knowing what aspects are checked, what format the results take, and how this differs from similar sibling tools. The description is minimally adequate but leaves significant gaps in understanding the tool's behavior and output.
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 description coverage is 100% (since there are no parameters to describe). The description appropriately doesn't discuss parameters since none exist. According to the scoring rules, 0 parameters = baseline 4, as there's nothing for the description to compensate for.
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 purpose: 'Verificar el estado de salud del sistema SVN y working copy' (Check the health status of the SVN system and working copy). It uses specific verbs ('verificar' - check/verify) and identifies the target resources (SVN system and working copy). However, it doesn't explicitly differentiate from sibling tools like 'svn_diagnose' or 'svn_status', which might have overlapping functionality.
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 doesn't mention when this health check is appropriate (e.g., troubleshooting, routine monitoring) or when other tools like 'svn_diagnose' or 'svn_status' might be better suited. There's no context about prerequisites, timing, or exclusions.
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 behavioral disclosure. It mentions clearing credentials cache to resolve authentication errors, which implies a mutation operation (clearing/deleting cached data). However, it doesn't disclose important behavioral traits such as whether this requires specific permissions, whether the action is reversible, what happens to current sessions, or potential side effects. For a mutation tool with zero annotation coverage, this 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?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose and intended use case. It's appropriately sized and front-loaded with the core action ('Limpiar cache de credenciales SVN') followed by the purpose ('para resolver errores de autenticación'). Every word earns its place with zero waste.
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 the tool's complexity (mutation operation affecting credentials), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It explains what the tool does and why, but doesn't cover important contextual aspects like what 'clearing' entails, whether it affects all users or just the current session, what authentication methods are impacted, or what the expected outcome looks like. For a credentials-related mutation tool, more completeness would be expected.
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 0 parameters, and schema description coverage is 100% (empty schema is fully documented). With no parameters to describe, the description doesn't need to add parameter semantics. The baseline for 0 parameters is 4, as there's no parameter information to provide beyond what the schema already indicates (no parameters).
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 purpose: 'Limpiar cache de credenciales SVN' (Clear SVN credentials cache) with the specific goal 'para resolver errores de autenticación' (to resolve authentication errors). It uses a specific verb ('Limpiar') and resource ('cache de credenciales SVN'), though it doesn't explicitly differentiate from sibling tools like 'svn_cleanup' or 'svn_diagnose' which might have overlapping purposes.
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 context ('para resolver errores de autenticación' - to resolve authentication errors), suggesting it should be used when authentication issues arise. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'svn_cleanup' or 'svn_diagnose', nor does it mention any prerequisites or exclusions.
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:

[![mcp-svn MCP server](https://glama.ai/mcp/servers/gcorroto/mcp-svn/badges/card.svg)](https://glama.ai/mcp/servers/gcorroto/mcp-svn)

Score Badge

Copy to your README.md:

[![mcp-svn MCP server](https://glama.ai/mcp/servers/gcorroto/mcp-svn/badges/score.svg)](https://glama.ai/mcp/servers/gcorroto/mcp-svn)

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/gcorroto/mcp-svn'

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