agentic-ecos
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between ecosystem_tasks and ecosystem_task_status, as both deal with task overview/state. Additionally, add_custom_pattern, promote_to_workspace, and promote_to_knowledge all involve adding patterns to different locations, though the contexts are clear.
Naming Consistency4/5All tool names use snake_case and mostly follow a verb_noun pattern (e.g., list_patterns, add_custom_preset, remove_custom_pattern). However, there are some deviations like 'connect' (bare verb) and 'rag_status' (noun_noun), and a mix of prefixes (ecosystem_, project_, agentic_) that slightly reduces consistency.
Tool Count2/5With 37 tools, the server exceeds the threshold for 'too many' (25+). The tool set could be consolidated, such as grouping git operations (ecosystem_branch_create, ecosystem_sync_upstream, ecosystem_merge_main) or task operations (add/claim/done/status) into fewer tools with parameters.
Completeness4/5The tool surface covers the core workflows of the agentic ecosystem domain: project initialization, validation, health reporting, pattern/protocol/preset management, agent connections, task management, git operations, and knowledge tiers. Minor gaps exist, such as no update/delete for tasks and no update for custom patterns, but these are workable.
Average 3.3/5 across 37 of 37 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 39 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.jsonto 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?
With no annotations, the description carries the full burden of disclosing behavior. It mentions the data source (workspace/tasks.md) and the per-project count, which gives some context, but it does not state whether the operation is read-only, whether any state changes occur, or what the exact output format is. The behavior is underspecified for an aggregation/report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, reasonably concise sentence with no filler words. However, it is not front-loaded with a verb and uses a noun phrase that may be ambiguous. It earns a middle score because it is efficient but lacks clarity in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description should explain the return value, the role of config_path, and typical use cases. It only hints at aggregation and per-project counts, leaving significant gaps in the agent's understanding of how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains a parameter 'config_path' with zero description coverage in both schema and description. The description does not mention this parameter at all, forcing the agent to guess its purpose. With 0% schema coverage, the description was expected to compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Agregado de tareas del ecosistema: cross-cutting (workspace/tasks.md) + conteo por proyecto' clearly indicates the resource (ecosystem tasks) and scope (cross-cutting and per-project count), but lacks an explicit verb like 'list' or 'get'. It distinguishes from mutating siblings like ecosystem_task_add and ecosystem_task_done by implying an aggregation/reporting view, but the purpose is still somewhat vague without a direct action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as ecosystem_task_status or ecosystem_task_done. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name 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?
The description mentions it detects if the project already has agentic infrastructure, but it does not explain what happens in that case, whether it modifies agentic.toml, or any side effects. With no annotations, the description carries the full burden of behavioral disclosure and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action and includes a useful parenthetical nuance. It wastes no words, but it is perhaps too terse for a tool with 7 parameters. Still, the structure is clean and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and zero parameter descriptions mean this description is woefully incomplete. For a tool with 7 parameters, an agent cannot determine return values, required fields beyond 'name', or side effects solely from this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 7 parameters with 0% schema description coverage, and the description does not mention any of them. It gives no clues about what 'path', 'type', 'preset', 'status', or other parameters mean, making correct invocation nearly impossible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Registra un proyecto en agentic.toml' (registers a project in agentic.toml), using a specific verb and resource. It also hints at a detection feature. However, it does not explicitly differentiate from sibling tools like init_project, which could also involve project setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as init_project or project_remove. It does not mention prerequisites, ideal use cases, or situations where another tool would be more appropriate.
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 state whether the tool performs a read-only scan, has side effects, requires configuration, or returns data. The word 'reporte' implies a read operation, but no explicit behavioral details are given, which is insufficient for an unannotated 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy or extraneous words. It effectively communicates the core purpose in a structured way. While it lacks necessary details, those are accounted for in other dimensions, and conciseness itself is appropriately maintained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, no annotations, and a single undocumented parameter, the description is insufficient for understanding the tool's full behavior, return values, or use cases. Sibling tools exist for specific status types, but the description does not explain how this status report integrates with or differs from them. The description leaves critical gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'config_path' is completely undocumented in both the schema and description. Schema description coverage is 0%, and the description does not compensate by explaining what config_path does, what format it expects, or when it should be provided. The AI agent is left without any meaningful information about the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a complete ecosystem health report covering projects, agentic coverage, and gaps. It is a specific noun phrase but lacks a direct verb; however, 'Reporte de salud' conveys the tool's action. It somewhat distinguishes from sibling tools by emphasizing 'completo' and enumerating covered areas, but does not fully differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of exclusions, prerequisites, or situations where other sibling tools like 'agentic_health' or 'storage_status' would be more appropriate. The description merely states what it does, leaving the AI agent without decision support.
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 'Devuelve' (returns), implying a read operation, but it does not explicitly state that it is safe, side-effect-free, or what happens if the pattern is not found. Beyond the primary action, no additional behavioral context is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to read and front-loaded with the main action. However, its brevity sacrifices important details, making it efficient but not fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description offers minimal context. It does not clarify what constitutes an 'agentic pattern' or how the implementation guide is structured, and it lacks any mention of related tools or expected return behavior, leaving the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'name' has no schema description (0% coverage), and the tool description does not explain that 'name' refers to the pattern's name. With no parameter information in either the schema or description, the agent is left to infer the parameter's meaning from the tool name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a specific agentic pattern along with implementation guidance, using a verb ('Devuelve') and a resource ('patrón agéntico'). While it doesn't explicitly differentiate from list_patterns, the word 'specific' implies single-item retrieval, which distinguishes it from listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_patterns or add_custom_pattern. The description only describes the function without any contextual cues, 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 must disclose behavioral traits. The term 'Reporte' implies a read-only operation, but the description does not explicitly state whether there are side effects, required permissions, or what the report output looks like. It also fails to clarify if the tool scans the project or simply summarizes existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core purpose and content. It avoids fluff, but its brevity contributes to under-specification in other dimensions. It earns a 4 for efficient, focused phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description must convey return information. It lists three report components (coverage, gaps, suggestions) but does not explain their meanings, structure, or how to interpret them. For a health-report tool, this is insufficient for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter, project_path. The description mentions 'proyecto' but does not explain the expected path format, whether it must exist, or how it is used to generate the report. The description adds minimal value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reporte de salud agéntica de un proyecto (coverage + gaps + sugerencias)' clearly indicates that the tool produces an agentic health report for a project, listing coverage, gaps, and suggestions. This goes beyond a simple tautology by specifying the resource and content, though it lacks an explicit verb like 'generate' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention the context, prerequisites, or any exclusion criteria. Sibling tools like 'validate_structure' or 'suggest_next_steps' are not referenced, leaving the agent to infer the appropriate usage from the name only.
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 hay anotaciones y la descripción no revela comportamientos adicionales como efectos secundarios, permisos necesarios, formato de salida o rendimiento. Solo indica la acción básica de escanear, dejando al agente sin información de contexto.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
La descripción es una sola oración breve y directa, sin información redundante. Cada palabra contribuye al propósito, y está bien estructurada para una lectura rápida.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Dado que no hay anotaciones, no hay esquema de salida y el único parámetro no está explicado, la descripción resulta insuficiente para que el agente comprenda completamente el comportamiento, los límites y los resultados esperados de la herramienta.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
La cobertura del esquema es 0% y la descripción no explica el parámetro 'workspace_root'. No se indica qué valores acepta, cómo afecta al comportamiento o si es obligatorio, lo que deja al agente sin orientación semántica.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
La descripción usa un verbo específico 'Escanea' y especifica el recurso (workspace) y el propósito (reportar proyectos con agentic-ecos conectado). Sin embargo, no diferencia explícitamente de herramientas hermanas como ecosystem_status o connect_status, por lo que no alcanza el máximo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No se proporciona ninguna orientación sobre cuándo usar esta herramienta frente a alternativas. No hay mención de contextos de uso, exclusiones o requisitos previos.
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 carry the full burden of behavioral disclosure. It only states that the tool suggests steps, but does not reveal whether it is read-only, what it returns, how it prioritizes, or if it has side effects. This is minimal transparency for a tool without structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that is front-loaded and free of fluff. It is appropriately concise for a tool with one parameter, though this brevity comes at the cost of missing behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It omits return value information, usage context, and parameter semantics, making it insufficient for an agent to confidently invoke the tool without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only implies 'project_path' through the word 'proyecto'. It does not clarify what constitutes a valid project_path, whether it is a filesystem path or project identifier, or any constraints. The description adds little value beyond the schema's bare property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with a specific verb ('Sugiere') and resource ('próximos pasos para un proyecto'), making it distinct from siblings like list_protocols or get_pattern. It could be more explicit about what kind of project or how it differs from other suggestion tools, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction on selecting this tool over siblings.
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 bears the full burden of behavioral disclosure. The verb 'Detecta' implies a read-only operation, but the description does not explicitly state whether it modifies anything, requires auth, or how it handles missing inputs. It also fails to define what 'connected' means or what happens when agentic-ecos is not connected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose with no redundant words. It is front-loaded and efficient, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns or how to interpret results, but it does not. It also lacks context on prerequisites, expected behavior, or dependencies beyond naming 'target'. For a status-checking tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare schema. It mentions 'target' as the location of configs, but 'config_path' is left unexplained. Neither parameter's role is fully clarified, and the description adds minimal semantic value beyond hinting at 'target'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Detecta' and names two concrete targets: which agents have config in target and whether agentic-ecos is connected. This makes the tool's purpose unambiguous. However, it does not explicitly distinguish this tool from sibling status tools like ecosystem_status or agentic_health, so it falls short of full 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/5Does 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 mentions no exclusions, prerequisites, or alternative tools, offering only a statement of function. There is no implied or explicit usage context.
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 side effects like file overwriting, permission requirements, or idempotency. The only behavioral hint is that it creates a file from a template, which is already implied by the name. This leaves significant transparency gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise and front-loaded. However, it is under-specified to the point of being potentially unhelpful, but conciseness itself is achieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters and no output schema, so the description needs to explain the inputs and any behavioral context. It is too minimal to be complete: there is no explanation of what the template is, how it is selected, or what context JSON should contain. The agent cannot reliably invoke this tool based on the current description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate. It mentions 'template' but does not clarify which parameter specifies the template. The parameters file_name, target_path, and context are not explained by the description, leaving the agent without guidance on how to populate them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating a single file from a template. The verb 'Genera' (generates) is specific, and the resource ('archivo individual') and source ('template') are identified. This distinguishes it from sibling tools like list_patterns or get_pattern, which retrieve patterns rather than generate 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/5Does 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, nor any exclusions or prerequisites. There is no mention of how it relates to sibling tools such as get_pattern or add_custom_pattern, leaving the agent to infer usage context.
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. The verb 'validate' implies a read-only operation, but the description does not confirm whether it has side effects, what happens if the project doesn't exist, what the output format is, or any permission requirements. This leaves the agent with insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It is front-loaded with the core action and resource, making it immediately scannable. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description must provide enough context for the agent to understand expected behavior. It lacks an explanation of what 'infrastructure pieces' includes, what a successful validation returns, and how this differs from similar sibling tools. The absence of this information makes the tool feel incomplete in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single required parameter 'project_path'. The description mentions 'in a project' but does not explicitly connect this to the parameter or clarify what value should be passed. There is no guidance on path format, whether it should be absolute or relative, or how it is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'validate' and identifies the resource as 'infrastructure pieces' within a project, providing a clear subject and scope. It distinguishes itself from siblings like 'list_patterns' or 'agentic_health' by focusing on validation of structural existence rather than listing or health status. However, 'qué piezas' is slightly ambiguous, as it could imply either validation against an expected set or simple enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit or implicit guidance on when to use this tool versus its many siblings. The description simply states what the tool does without mentioning circumstances, preconditions, or alternative tools. For a tool in a large family like this, this is a significant gap.
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 bears the full burden of behavioral disclosure. It only states a return value and does not mention side effects, permissions, error behavior, or whether it is read-only. While 'Devuelve' implies a read operation, no additional behavioral context is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose in a concise and readable manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and omits important context such as the meaning of config_path, return format, and any behavioral caveats. While the tool is simple, the missing parameter explanation and lack of output details make it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter, config_path, with zero schema description coverage. The tool description does not mention or explain this parameter at all, providing no added meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the complete agentic.toml record, naming the specific resource and scope. It is distinguishable from siblings by the resource name, but it does not explicitly contrast with alternatives like ecosystem_status or ecosystem_init, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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. The implied usage is 'retrieve the full agentic.toml configuration,' but there is no mention of prerequisites, exclusions, or related tools, so the usage context is only implicit.
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 exist, so the description must carry the transparency burden. It only hints at behavior by mentioning the file and commitability, but fails to disclose side effects, whether the task is appended or overwrites, or any prerequisites. This is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that uses every word to convey the core action and destination, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters, lack of annotations, and no output schema, the one-sentence description is incomplete. It omits return values, side effects, parameter semantics, and any operational details needed to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description does not explain any of them. Parameters like type, scope, priority, and config_path are left entirely undefined, making it difficult to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Agrega una tarea cross-cutting al workspace/tasks.md' (adds a cross-cutting task to workspace/tasks.md), specifying the action and target resource. It also notes commitability on the branch, distinguishing it from task listing/claim/status siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage context (cross-cutting, commitable) but no explicit guidance on when to use this tool versus siblings like ecosystem_task_claim, ecosystem_task_done, or project_add. There are no stated exclusions or alternative recommendations.
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 full behavioral disclosure. It only states the action and destination file, but omits details about file creation, merging, overwriting, validation, or permissions. This is minimal disclosure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for the action it states, though it may be too brief to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and two params with zero description coverage, this one-liner is incomplete. It lacks mention of return values, error cases, and behavioral nuances like whether it overwrites existing presets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it does not describe either the 'name' or 'preset' parameter, providing no guidance on their format or purpose beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Agrega' = adds) and specifies the resource ('un preset custom') and exact target file ('data/presets-custom.json'). This clearly distinguishes it from sibling tools like add_custom_pattern or remove_custom_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you want to add a custom preset. However, there is no explicit guidance on when to use it over alternatives or any exclusions, so it only meets the 'implied usage' level.
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 fully disclose behavioral traits. It states the action and destination but does not mention whether existing snapshots are overwritten, naming conventions, permissions, or the expected payload structure. The description adds minimal context beyond the tool's name and action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and location. It contains no redundant words, is front-loaded with the verb, and every part adds value. The structure is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (including a nested object), no annotations, and no output schema, the description is severely incomplete. It omits parameter semantics, side effects, return behavior, and any prerequisites. An agent cannot reliably invoke this tool correctly based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the 'label' or 'payload' parameters. Schema coverage is 0%, so the description needed to compensate but did not. The example hints that payload might relate to ecosystem status, but this is not explicit, leaving parameter meaning entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a historical snapshot to a specific directory, using the verb 'Guarda' and resource 'snapshot histórico'. The example 'ej: de ecosystem_status' clarifies the intended use, and the destination path adds specificity. This distinguishes it from sibling tools like ecosystem_status, which presumably reports rather than saves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the example 'de ecosystem_status' but provides no explicit when-to-use guidance or mention of alternatives. It does not state when to prefer this tool over others, nor does it describe exclusions. The usage context is only implied, not fully specified.
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?
Without annotations, the description must disclose side effects and behavior. It states that agentic.toml is created, but does not mention overwrite behavior, required permissions, or the effect of the 'scan' parameter (e.g., auto-detecting existing projects). This is a significant gap for a tool that writes configuration files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the core function. It is concise with no superfluous words, and every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, low schema coverage, and absence of an output schema, the description is too sparse to be complete. It leaves unclear what happens if agentic.toml already exists, what the created config contains, and how parameters map to behavior. This is inadequate for a tool with 9 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22% (only workspace_root and scan have descriptions). The description does not compensate by explaining any of the 9 parameters or their defaults. For example, it does not clarify what 'defaults' are stored or how 'scan' influences behavior, leaving the agent to rely on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Inicializa el plano de control: crea agentic.toml en el workspace con registro canónico de proyectos y sus defaults.' It uses specific verbs (inicializa/crea) and a specific resource (agentic.toml), which distinguishes it from sibling init_project by focusing on the control plane level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 init_project or ecosystem_config. It only states what it does, without mentioning prerequisites, exclusions, or typical scenarios. The user must infer usage context solely from the name and description.
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 disclosing side effects, preconditions, and success criteria. It merely lists what will be generated but does not mention whether existing files are overwritten, whether network access is required, what happens on repeated runs, or any error conditions. For a tool that creates a comprehensive infrastructure skeleton, these are critical gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the tool's function. There is no redundant or filler content, and the key components are listed in parentheses for quick scanning. Given its brevity, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 8 parameters, no annotations, and no output schema. The description is far too brief to provide adequate context for correct usage. It lacks information about parameter effects, expected outcomes, or how to use the tool within a workflow, especially when considering the low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38% (3/8 parameters have descriptions). The tool description does not explain any of the parameters (ci_cd, cloud, language, target_path, etc.) nor map the listed components to specific parameters. It fails to compensate for the low schema coverage, leaving the meaning of several parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Genera el esqueleto completo de infraestructura agéntica en un proyecto' with a specific list of generated components (locks, tasks, comms, session audit, protocols, vault, MCP skeleton). This goes beyond the tool name and distinguishes it from sibling tools like generate_file or ecosystem_init by specifying a comprehensive project skeleton.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no exclusions. It only states what the tool does, leaving the user to infer the appropriate context. No mention of sibling tools or when a different tool might be more suitable.
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?
With no annotations, the description carries the transparency burden. The word 'returns' indicates a read operation without side effects, but it does not disclose behavior on invalid inputs, required permissions, or output format. This is minimal but acceptable for a simple retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action ('Devuelve'). No unnecessary words, appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature (2 params, no output schema), but the description omits crucial details like the meaning of 'name' and the expected format of 'context'. While the schema fills in 'context' partially, the overall documentation is sufficient for basic use but lacks depth for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'context' as optional JSON, but 'name' lacks a description. The tool description does not explicitly map parameters to the action, relying on inference from the tool name and the 'placeholders' phrase. It partially compensates for schema coverage but leaves 'name' ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: returning a protocol template with placeholders replaced. This distinguishes it from siblings like list_protocols and get_pattern, though it does not elaborate on the template's purpose or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_pattern or list_protocols. It only states the action without contextual cues 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?
With no annotations, the description carries full burden. It mentions the file path but does not disclose side effects (e.g., permanence, error on missing preset, file deletion if last item) or any required permissions. For a destructive operation, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, immediately front-loading the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema), but given there are no annotations, the description should at least mention error behavior or that it's a destructive operation. It only states the literal action without surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required param 'name', but the description does not explain what 'name' refers to. Schema coverage is 0%, so the description should compensate, but it doesn't. The param is somewhat self-explanatory given the tool name, but the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Elimina' = remove) and the specific resource ('un preset custom de data/presets-custom.json'), making it unambiguous and distinct from sibling tools like remove_custom_pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives, nor any preconditions or exclusions. It is a bare statement of what it does.
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. It discloses that it modifies a file, implying a destructive deletion, but does not state whether the operation is irreversible, what happens if the pattern does not exist, or any side effects. Given this is a mutation tool, more behavioral disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that is front-loaded and free of redundancy. Every word earns its place, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so minimal context is acceptable. The description names the target file, giving some context. However, it lacks behavior on error cases or return values, leaving gaps for an agent using it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies the 'name' parameter is the identifier of the pattern to remove, but does not clarify case sensitivity, exact naming conventions, or whether the full filename is expected. Minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Elimina' = removes) and the resource ('un patrón custom') with a specific file location ('data/patterns-custom.json'). It distinguishes from siblings like remove_custom_preset (different resource) and add_custom_pattern (opposite operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention that it is specifically for patterns and not presets, nor does it explain any prerequisites or conditions. The description is purely definitional with no contextual usage notes.
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. It mentions that existing configs of other servers are not modified, which is useful, but it does not disclose side effects, required permissions, reversibility, or what exactly gets changed on the target system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word adds value. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is insufficient. It covers the core purpose but provides no context on return values, required inputs, or how the tool behaves in different scenarios, leaving many operational details unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, so the description should compensate for undocumented parameters. It does not: it only lists agent types, which are already in the schema's 'agent' parameter description. No additional meaning is added for target, config_path, agentic_path, or create_if_missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures agentic-ecos as an MCP server for one or more agents, listing specific agent types. This distinguishes it from siblings like connect_status, which presumably checks status rather than performing configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this to set up MCP server for agents. The note 'No modifica configs existentes de otros servers' provides a safety reassurance, but there is no explicit guidance on when not to use it or which alternative to prefer.
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 full responsibility. It says 'Consulta' (consult), implying a read-only operation, but does not disclose prerequisites, error behavior, or the return format. The purpose of the tasks_file parameter is also left opaque, creating ambiguity about 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently communicates the core action and filter options. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and any dependencies. It does not describe the response structure, nor does it clarify the tasks_file parameter. The description is too sparse to fully guide an agent, especially for a tool with three optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It adds meaning for task_id ('por ID') but merely repeats the filter_agent enum values already present in the schema. The tasks_file parameter is completely unexplained in both the schema and description, leaving a significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: querying task status by ID or filtered by agent/status. It lists concrete filter values (unclaimed, claimed, done, backlog, agent-id), which distinguishes it from sibling tools like ecosystem_task_claim or ecosystem_task_done that modify tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage scenarios (query by ID or filter by agent/status) but does not explicitly contrast with sibling tools or state when not to use this tool. There is no mention of alternatives or exclusions, so the agent must infer when to use this over other task-related tools.
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?
With no annotations provided, the description carries the full burden. 'Verifica' implies a read-only, non-destructive action, but the description does not disclose return values, error behavior, or edge cases (e.g., what happens if the vault is not indexed). It provides minimal but non-contradictory 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly states the tool's purpose. There is no filler, repetition, or unnecessary detail. It earns its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a minimal schema and no output schema, but the description still leaves gaps: it does not explain the meaning of target_path, what 'opt-in' entails, or what kind of status output to expect. Given the lack of annotations, the description is under-specified for complete understanding, despite the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists a single optional parameter, target_path, with no description and 0% schema coverage. The tool description does not mention or explain target_path at all, leaving its purpose completely unclear. The description fails to add any meaning beyond the raw schema field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: checking whether the project vault is indexed for RAG. The verb 'Verifica' (checks) plus the resource ('vault del proyecto indexado para RAG') provides a specific and actionable purpose. It differentiates from sibling status tools like connect_status or knowledge_status by explicitly focusing on RAG indexing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention of 'opt-in' gives an implied usage condition: the tool is only relevant for projects that opted into RAG. However, there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. It leaves the agent to infer the appropriate 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?
With no annotations, the description carries the behavioral transparency burden. It discloses the persistence location 'data/state.json', which is useful context, but it does not reveal whether existing keys are overwritten, whether value is optional despite the schema, or any potential side effects. This is a minimal but not misleading disclosure, so it earns a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately states the action and target. There is no wasted text, and the key information is front-loaded. This is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with no output schema, the description is adequate but incomplete. It lacks details about overwrite behavior, the optional nature of 'value', and how the stored state might be retrieved or affected by other tools. The minimalism leaves some gaps, but the core purpose is clear enough to warrant a mid-range score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only repeats the concept of 'clave/valor' (key/value) without adding meaning about the types, formats, or optionality of the value parameter. It does not explain what kind of objects are acceptable or how the key is used, leaving parameter semantics largely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Guarda una clave/valor en el estado interno del MCP (data/state.json)' (saves a key/value in the internal MCP state). It uses a specific verb and resource, and the mention of 'internal state' distinguishes it from sibling tools that operate on custom patterns, presets, or ecosystem data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are there exclusions or prerequisites. The description does not mention when a user should prefer set_state over other state-related tools like storage_status or the various add_* commands.
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 does reveal a side effect: 'Trazable: registra la operación en AGENT_SESSION_LOG' (records the operation in AGENT_SESSION_LOG), which is useful. However, it omits critical behaviors such as what happens if the branch already exists, whether it checks out the branch, or any permission requirements. The mutation is not fully characterized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a brief traceability note, front-loaded with the core action. It is extremely concise with no wasted words, earning the maximum score for structure and size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema and no annotations, the description is minimally adequate but incomplete. It covers the basic creation and logging aspect but does not address error handling, preconditions (e.g., whether the ecosystem must be initialized), or post-conditions. Given the lack of supplementary structured data, it could have provided more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the 'name' parameter by showing it becomes part of the branch name template `ecosystem/{name}`, which the schema does not describe. For 'base', it reinforces the default and matches the schema's description. This adds meaning beyond the schema, especially since schema coverage is only 50%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Crea la branch `ecosystem/{name}` desde `base`' (Creates the branch ecosystem/{name} from base). It specifies the exact resource (branch) and action (create), distinguishing it from sibling tools like ecosystem_merge_main or ecosystem_init.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description mentions the default base and traceability but does not state prerequisites, exclusions, or contrast with sibling tools. It provides no context like 'use this for new feature branches' or 'do not use if the branch already exists.'
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 must carry full behavioral disclosure. It merely states the action without specifying whether it is read-only, what the return structure is, or how the domain filter behaves (e.g., exact match, case sensitivity).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the main function and optional filter. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the essential action and the optional filter. However, with no output schema and no annotations, it would benefit from mentioning the return type (e.g., list of pattern names) or any pagination/ordering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a domain parameter with a default of null and no description. The description adds that the domain filter is optional, clarifying the param's purpose, but does not detail accepted values or filtering semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available agentic patterns, with an optional domain filter. It distinguishes from sibling tools like get_pattern (retrieves a single pattern) and add/remove custom pattern tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing patterns and shows that domain is an optional filter. However, it does not explicitly state when to prefer this over alternatives like get_pattern or list_protocols, nor does it mention exclusions.
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?
With no annotations provided, the description carries the full burden. It does disclose the key behavioral effect: the project is eliminated from the registry. Yet it omits details such as whether the operation is reversible, whether project files are also deleted, and how config_path influences the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that directly states the tool's purpose with no wasted words. It is appropriately sized for a simple removal tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the absence of annotations, no output schema, and undocumented config_path leave important gaps. The description is enough to know the basic purpose but not enough to understand optional behavior or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not mention either parameter. The 'name' parameter is somewhat self-explanatory, but 'config_path' with a default of null is not described, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Elimina un proyecto') and the exact resource affected ('del registro agentic.toml'). This distinguishes it from sibling tools like project_add and remove_custom_pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a project needs to be removed from the agentic.toml registry. However, it does not explicitly mention when not to use it or compare it with alternative removal 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?
No annotations are provided, so the description must fully disclose behavior. It only says 'Mueve' (moves) without explaining side effects on the original file, reversibility, permissions, or behavior on conflicts. This is under-specified 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and provides specific source/destination context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 too sparse. It lacks information about return values, side effects, prerequisites, or error conditions, which are essential for a move operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention parameters. 'un pattern' hints that 'name' identifies the pattern, but 'config_path' is completely unexplained. The description fails to compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mueve' - moves) and the specific resource: patterns from 'data/' to 'workspace/patterns/'. It also adds context about the destination being committable in the ecosystem branch, which distinguishes it from sibling tools like 'promote_to_knowledge'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: moving personal patterns to a shared, version-controlled workspace. However, it does not explicitly state when to use this tool versus alternatives like 'promote_to_knowledge' or provide 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. It indicates the tool reports knowledge status, implying a read-only operation, but does not explicitly state that it has no side effects, what the output structure is, or any permissions needed. The tier enumeration is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, with no redundant words or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status-reporting tool, the description is largely sufficient: it names the resource (knowledge), the grouping (tier), and lists the tiers. However, it doesn't specify what aspects of status are reported (e.g., counts, health, versions), and without an output schema, the agent has limited knowledge of the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. The description correctly focuses on the tool's behavior; the baseline for zero-parameter tools is 4, and no additional param semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Reporta' (reports) with the resource 'estado del conocimiento' and explicitly enumerates the tiers (built-in/knowledge/workspace/custom), making its function unambiguous and differentiated from sibling status tools like rag_status or storage_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling status tools (rag_status, storage_status, etc.), nor any conditions or prerequisites. It only states the function.
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?
The description discloses the mutation target (data/patterns-custom.json) and that it is available for all projects, plus a lifecycle hint. However, it does not reveal potential side effects like overwriting, error handling, or permissions, and no annotations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, and includes the essential file location and lifecycle guidance without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple add operation: it covers purpose, destination, and availability. However, missing parameter schema details and behavioral edge cases prevent it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only declares a single object parameter with no descriptions, and the description does not elaborate on required fields or structure of the pattern object. The phrase 'patrón agéntico descubierto por un agente' provides only a general notion, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds an agent-discovered pattern to data/patterns-custom.json, using a specific verb and resource. It distinguishes from sibling read/removal tools by mentioning the file destination and pattern type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context that patterns are agent-discovered and stored in the custom file, with promotion to patterns.py when mature. However, it does not explicitly name alternative tools or state when not to use it.
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 present, so the description carries the burden. The verb 'list' implies a read-only operation, but the description does not explicitly state safety, return format, or other behavioral traits. It is acceptable for a simple list 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded, informative, and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description adequately conveys the core functionality. It could mention the output format, but given the simplicity and lack of output schema, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. Per the rubric, a baseline of 4 applies for 0 params, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available project type presets with a specific verb and resource. It distinguishes from siblings like list_patterns and list_protocols by specifying 'presets de tipos de proyecto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It simply states what it does without mentioning that list_patterns or list_protocols exist for other resource types, leaving the agent to infer usage.
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?
With no annotations present, the description carries the full burden of behavioral disclosure. It states the tool lists available protocol templates, which clearly implies a read-only listing action. However, it does not describe return format, sorting, or whether the list includes full details or just names. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. There is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides enough to understand the primary action. It could be enhanced by indicating what the returned list contains (e.g., names, IDs, or full template objects), but the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The baseline for 0 params is 4, and the description adds no parameter-specific detail, which is not needed. The absence of parameters makes this score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista las plantillas de protocolos disponibles' uses a specific verb ('Lista' / list) and a clear resource ('plantillas de protocolos disponibles' / available protocol templates). It distinguishes itself from sibling tools like list_patterns and list_presets by focusing on protocol templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives such as list_patterns or list_presets. It does not mention prerequisites, exclusions, or contextual clues. For a simple listing tool, this is a minor gap, but the dimension requires explicit 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?
With no annotations, the description carries the burden of behavioral disclosure. It states that the operation is a copy (non-destructive) and that the result is committable, which adds context beyond the name. Still, it does not mention potential overwrite behavior, prerequisites, or side effects on the source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core action and resources, with a brief parenthetical purpose. Every word contributes meaning, and it avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and purpose, but gaps remain: it does not clarify the meaning of 'name', the full range of kinds (preset/trap), or prerequisites for the knowledge directory. Given the tool's simplicity and the schema's coverage, it is minimally adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description reinforces the meaning of the 'source' parameter by mapping it to directory names (workspace/ or data/). It does not explain the required 'name' parameter or clarify that 'kind' can be preset/trap despite the schema providing those enums. The description adds modest value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (copy), the source directories (workspace/ or data/), the destination (knowledge/), and the purpose (commitable for an upstream PR). This distinguishes it from the sibling tool promote_to_workspace, which would target a different destination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when you want to make a pattern available for an upstream PR. It also implies the tool is relevant for workspace/data to knowledge promotion. However, it does not explicitly contrast with alternatives like promote_to_workspace or state when not to use it.
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 transparency burden. It discloses that conflicts are reported and that either target_branch or the current branch is used, which adds behavioral context. However, it does not mention potential side effects such as file modifications, uncommitted changes, or the need for a clean working tree, which are important for a merge 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and includes essential qualifiers (branch choice and conflict reporting). It is appropriately sized with no wasted words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description reasonably covers the main purpose, the branch selection logic, and the conflict reporting outcome. It is missing details about the merge's side effects (e.g., working tree changes, commit behavior) and prerequisites, but for a simple merge tool, the description is sufficiently complete for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only a parameter name and default null with no description, giving 0% schema coverage. The description compensates by explaining that target_branch specifies the ecosystem branch and if it is not provided, the current branch is used. This adds meaningful semantics beyond the schema, though it could be more explicit about the format or null behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('mergea main' = merge main) and the target resource (the ecosystem branch, either target_branch or current branch). This distinguishes it from sibling tools like ecosystem_branch_create or ecosystem_sync_upstream, making the tool's specific function immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when merging main into an ecosystem branch) but does not explicitly mention alternatives or exclusions. It lacks a clear 'when not to use' or comparison with siblings like ecosystem_sync_upstream, leaving usage guidance mostly implied.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool reports, and the verb 'Reporta' suggests a read-only operation, but it does not explicitly confirm that it has no side effects or describe any potential limitations. This is adequate but leaves room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and scope, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description sufficiently explains what the tool reports and the domain it covers. It could mention return format, but that is not critical for a basic status operation. The description is complete enough for its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already covers this fully. Per the rubric, a 0-parameter tool receives a baseline of 4, and the description does not need to add parameter details. It correctly focuses on the output semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reporta') and clearly identifies the resource ('almacenamiento orgánico (data/)'), enumerating the covered aspects: custom patterns/presets, snapshots, state. This distinguishes it from sibling status tools like rag_status or ecosystem_status by making the storage focus explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing storage status), but it does not explicitly contrast it with alternative status tools or mention any exclusions. While the resource is clear, there is no direct guidance on tool selection among the many sibling status tools.
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 provided, the description carries the full burden and does well by disclosing key behavioral traits: it mutates status to 'done', performs a git commit and push, and validates agent ownership. These side effects go beyond the schema and inform the agent of the tool's impact. It does not, however, detail failure modes or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the primary action and then adding the ownership verification as a supporting detail. No redundant information or filler, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the core action and side effects but omits return value, error conditions, and the meaning of the optional tasks_file. It is adequate for basic selection and invocation but not fully complete for a tool with mutating side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly clarifies task_id and agent_id through the ownership check, but tasks_file remains unexplained, and no types, defaults, or formats are provided. This partially bridges the schema gap but leaves one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Marca' (marks) and clearly identifies the resource (a task) and the exact action: set status to done, commit, and push. It distinguishes from sibling tools like ecosystem_task_add and ecosystem_task_claim by focusing specifically on completion, making its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The ownership verification requirement ('Verifica que el agent_id que completa es el que la reclamó') implies the tool should be used only when the calling agent is the one who claimed the task, providing clear contextual guidance. However, it does not explicitly mention alternatives or when-not-to-use cases beyond the ownership condition.
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?
With no annotations, the description must disclose behavioral traits on its own. It does reveal the core git fetch + merge operation and the branch-specific impact. However, it omits important details such as how merge conflicts are handled, whether a clean working tree is required, or if the operation is reversible, which are relevant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the action and efficiently incorporates the branch-specific details. There is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the essential operation and branch nuances. It lacks details on prerequisites, error conditions, or side effects, but given the tool's simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'branch' parameter with 100% coverage ('main | dev'). The description adds meaningful context beyond the schema by explaining that main updates the stable branch and dev updates the bleeding edge, which helps the agent select the correct parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it synchronizes a local branch with upstream via 'git fetch + merge'. It also specifies the two branch options (main and dev) with their distinct roles, making it unambiguous and distinct from sibling tools like ecosystem_merge_main.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool and how to choose the branch: 'main' for stable updates and 'dev' for bleeding-edge updates. However, it does not explicitly mention alternative tools or exclusion scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it discloses that the tool performs a commit and push, is race-free via git push rejection, and fails if another agent claimed first. This is rich behavioral detail beyond a simple 'claim' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose and provide key behavioral details without redundancy. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description gives good behavioral context but omits parameter explanations and preconditions. It is adequate but leaves gaps in understanding how to use the parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely mentions 'T-ID' for task_id and does not clarify agent_id or tasks_file semantics, formats, or defaults. This fails to add meaningful meaning beyond the bare schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Reclama una tarea' (claim a task) and details the exact actions: adds [agent::], sets [status:: doing], commits, and pushes. It also mentions the race-free behavior, clearly distinguishing it from sibling tools like ecosystem_task_add or ecosystem_task_done.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (claiming a task) and describes the failure condition under race (if another agent claimed first). However, it does not explicitly name alternative tools or state exclusions, though the sibling tools make the distinction implicit.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/deibanez/agentic-ecos'
If you have feedback or need assistance with the MCP directory API, please join our Discord server