code-context-storage-mcp

by Jrains-ux

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation1/5
The tool set is extremely large with many overlapping names. For example, there are multiple 'confirm' tools (semantic_confirm, business_mapping_confirm, knowledge_confirm, confirm) and many 'validate' tools (code_facts_validate, edge_validate, node_semantic_validate, business_candidates_validate, business_mappings_validate). Generic verbs like 'update', 'query', 'publish', and 'job' further blur boundaries, making it nearly impossible for an agent to reliably select the correct tool without detailed descriptions.
Naming Consistency2/5
Most tool names use snake_case, but the pattern is inconsistent. Some follow verb_noun (e.g., list_scopes, list_domains, search_nodes), but many invert to noun_verb (e.g., graph_context_get, node_batch_get) or use awkward structures like 'business_directory_batch_upsert'. Additionally, several tools are single words without a pattern (e.g., ingest, update, push, query, status, health), which breaks consistency.
Tool Count1/5
With 77 tools, the server is excessively large for a typical MCP context. The stated domain of code-context-storage is not so broad as to justify this number, especially when many tools appear to be variations of the same operation (e.g., multiple upsert, validate, and confirm tools). This creates a maintenance and selection burden without clear benefit.
Completeness2/5
Despite the massive number of tools, there are notable gaps. For instance, there are upsert operations for nodes, edges, and business mappings but no corresponding delete or remove operations. Similarly, there are get and search operations but no clear lifecycle management for jobs beyond cancel/resume. The bloat suggests coverage is scattered rather than systematically complete.
Average 1.1/5 across 77 of 77 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 57 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'Upsert' implies insert/update, but the description does not explain behavior on conflicts, idempotency, validation, or any side effects. Both schema and description are silent on these crucial aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, it is extremely short but this is under-specification, not conciseness. There is no structure, no front-loading of key constraints, and no additional information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with nested objects, six parameters, and no output schema. Without any description of parameters, behavior, or return values, an agent has virtually no chance of using it correctly. Complete inadequacy for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters, but it provides none. The required 'context' (with repository_id and target_commit) and 'edges' array are entirely undocumented. An agent cannot determine what data to supply or how to structure it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'edge batch upsert' is little more than a restatement of the tool name. It fails to specify what an 'edge' is, what operation is performed, or what the batch upsert accomplishes. An agent cannot infer the tool's purpose beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its many siblings (e.g., edge_validate, node_semantic_batch_upsert, business_directory_batch_upsert). There is no mention of prerequisites, alternatives, or conditions that should select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails entirely - there is no mention of side effects, whether the operation is read-only or mutating, permission requirements, or return behavior. The phrase 'evaluation run' hints at executing something, but nothing is exposed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is severely under-specified rather than concisely effective. It provides no useful information, so brevity here is a detriment, not a strength. The one-sentence description wastes its only opportunity to convey meaning and offers no structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, 5 of them required, with nested objects and no output schema. Without any behavioral or parameter description, the agent cannot know what inputs to provide, what the tool produces, or what side effects occur. This is completely inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for any of the 11 parameters (5 required, including repository_id, snapshot_id, source_revision, golden_set_id, golden_set_version). The description adds zero parameter information, leaving the agent to guess what each field means and how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'evaluation run' is a tautology that merely restates the tool name. It does not state what the tool does, what action it performs, or what resource it acts on. There is no verb or object that distinguishes it from any sibling tool like evaluation_golden_set or evaluation_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description provides no context about the intended use case, prerequisites, or situations where another tool would be more appropriate. An agent is left completely without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description is just a fragment and discloses nothing about side effects, whether it's read-only, pagination behavior, error conditions, or the return format. This is a complete failure to add 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.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, this is not conciseness but severe under-specification. The description contains zero informative content, only a phrase that mirrors the tool name. It has no structure, no front-loaded key information, and every word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no output schema, no annotations), the description is utterly inadequate. An agent cannot determine how to call this tool, what it returns, or why it differs from siblings. The description fails to cover even the basics required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter explanations whatsoever. With 8 parameters and 3 required (repository_id, target_commit, evidence_ids), the description adds zero meaning, not even hinting what these parameters do. The burden is entirely on the schema, which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'evidence batch get' merely restates the tool name with no elaboration. It lacks a specific verb or resource description beyond the name itself, and provides no differentiation from siblings like evidence_get or node_batch_get. This is a tautology that gives an agent no clue about actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. No mention of use cases, prerequisites, exclusions, or when to prefer other tools like evidence_get or dict_read. An agent has no context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It discloses nothing—no side effects, permissions, return format, or operational characteristics. The agent is left with zero insight into what happens when this tool is called.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While brief, this is severe under-specification rather than effective conciseness. The description provides no organized information, front-loaded or otherwise, and fails to earn its place as a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no annotations, a complete description is essential. This description provides almost nothing, making it impossible for an agent to use the tool correctly or understand its behavior. It is completely inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains 10 parameters with 0% description coverage, and the description adds no meaning to any of them. The description does not explain what edge_ids, node_ids, snapshot_id, or any other parameter represents, leaving the agent unable to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a verbatim restatement of the tool name ('evidence get') with no additional information about what the tool does, what resource it operates on, or its scope. It is a pure tautology and provides no value beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool versus any of its numerous siblings (e.g., evidence_batch_get, evidence_verify, get_nodes). The description gives the agent no context to differentiate it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior entirely. It states nothing about side effects, read/write nature, permissions, or what happens when verification fails. The agent cannot anticipate any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is extremely short, it is under-specification rather than meaningful conciseness. It provides no substantive content to front-load, so the tool name is the only 'structure' – and that is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, a nested object, no output schema, and no description, the tool is almost entirely opaque. The agent cannot know input requirements, expected output, error behavior, or how this fits into the broader workflow. Complete inadequacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds nothing about the 13 parameters (including context, end_line, source_hash, etc.). Without any schema hints or descriptive text, the agent has no idea what these parameters mean or how they relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'evidence verify' is a tautology – it simply repeats the tool name without stating the verb, resource, or action. It does not distinguish this from any of the 80+ sibling tools, nor does it explain what 'verify' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus alternatives like evidence_batch_get, code_facts_validate, or semantic_confirm. An agent has zero context to choose this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It says nothing about side effects, data modifications, authentication requirements, or any other behavior beyond the vague verb 'ingest'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word with no structure or content. This is not conciseness but severe under-specification; there is no sentence, no front-loading, and no earned content. It fails to serve any informational purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects, no output schema), this description is completely inadequate. An agent has no idea what 'ingest' does, what it returns, or how to invoke it correctly. The description is wholly insufficient for any meaningful use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving all 10 parameters (5 required) undocumented. The description provides no explanation of what the parameters mean, how they relate, or what values are expected. It fails to compensate for the extremely low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description offers no context on appropriate use cases, preconditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether this is a read-only operation, what data it returns, whether it requires special permissions, or any side effects. The description adds zero behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is not conciseness—it is under-specification. It provides no value and fails to convey essential information. A helpful description would be brief yet informative; this one is just empty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no output schema, no annotations, and no meaningful description, it is completely inadequate for an agent to understand what the tool does, when to use it, or how to invoke it correctly. Nothing about the context is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not. With 9 parameters (2 required) and no explanations, the agent cannot infer what values to provide or what each parameter means. The description is completely silent on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list scopes' is a tautology that merely restates the tool name. It does not define what a 'scope' is, what the tool does with them, or how it differs from sibling tools like list_domains or list_contexts. The verb 'list' is generic and the resource 'scopes' is undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 any of the many sibling tools. No mention of prerequisites, typical use cases, or alternative tools. The agent is left entirely without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing behavior. It does not mention read/write nature, pagination, rate limits, or any side effects. The agent has zero insight into what happens when the tool is called.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, this is under-specified rather than concise. It contains no useful structure, no front-loading of key constraints, and fails to earn its place as a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, 3 required, no output schema, and no annotations, this description is wholly inadequate. It discloses nothing about return values, error conditions, or operational context, making correct invocation improbable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it does not mention any. The three required parameters (repository_id, target_commit, terms) receive no semantic clarification, making it impossible to know what values are expected or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'search nodes' is a near-tautology of the tool name, providing no verb-resource detail or distinctions from siblings such as get_nodes or search_paths. It fails to state what specific nodes are being searched or what search entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. There is no mention of context, prerequisites, or exclusions, leaving the agent without any basis for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral aspects such as side effects, required permissions, or return behavior. The phrase 'skill events' gives no indication of what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is short, it is not concise in the meaningful sense; it is under-specified. A two-word phrase that merely echoes the name is not content that earns its place—it provides no information at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no output schema, and no annotations, the description is completely inadequate. An agent has no idea what this tool does, what inputs mean, or what to expect in return. This is worse than a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the five parameters (job_id, trace_id, request_id, tool_version, schema_version). All are just raw strings with no explanation of their purpose or format. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'skill events' is a restatement of the tool name, providing no verb or resource. It does not state what the tool does, what an event is, or how it relates to skills. This is a tautology with zero informative value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 or which alternatives to prefer. With numerous sibling tools, no context or differentiation is provided, leaving the agent to guess the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'skill trigger' reveals nothing about side effects, permissions, payload requirements, or return behavior. This is a serious gap for a mutation-like tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, this is under-specification, not conciseness. It omits essential information and is far from minimally viable for a tool with this parameter count and no other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely inadequate. Ten parameters, no output schema, no annotations, and a tautological description. An agent cannot determine what this tool does, how to call it, or what the expected outcome is. It is not viable for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds zero explanation for any of the 10 parameters. The agent has no idea what 'trigger_text', 'skill_name', or 'payload' mean in this context. The description does nothing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology ('skill trigger' restates the tool name). It provides no verb, resource, or scope information that would distinguish it from the many sibling tools like skill_status or skill_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. None of the 80+ sibling tools are referenced or compared, and no context for appropriate invocation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it discloses nothing about side effects, mutation, permissions, return values, or computational bounds. The agent has no idea whether this is a read-only analysis or something that changes state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than efficient conciseness. Every word is wasted because it restates the name, providing no actionable content. There is no structure or front-loading of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 parameters, no output schema, and no annotations, the description is completely inadequate. An agent would be unable to determine required parameter semantics, optional parameter effects, or expected results. This is critically incomplete for any real usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists 15 parameters with zero description in the schema and zero description coverage. The tool description adds no meaning to any parameter. With no guidance on what 'depth', 'direction', 'edge_budget', or 'node_id' mean in this context, the agent cannot correctly construct a request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'analyze impact' is a tautology that restates the tool name without specifying what impact means, what resource is analyzed, or how it differs from sibling tools like traverse_graph or find_paths. It provides no verb-object clarity beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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, when not to use it, or which alternatives might be more appropriate. Given the large sibling set of graph traversal and context tools, the absence of any usage context leaves the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a description that only states the name, there is zero behavioral disclosure. The agent cannot infer side effects, required permissions, or operation traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not effective conciseness. It provides no actionable content, so brevity offers no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (2 required) and no output schema, this description is completely insufficient. An agent has no idea what the tool expects, returns, or how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. The parameters (context, candidates, request_id, etc.) are entirely unexplained, including the required nested structures.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'business candidates validate', which merely restates the tool name with no verb, resource, or distinguishing detail. It does not clarify what the tool does or how it differs from sibling validation tools like code_facts_validate or business_mappings_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description provides no context, prerequisites, or exclusions, leaving the agent without any basis for selecting it over other validation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral aspects. It says nothing about side effects, required permissions, read-only vs. mutation, pagination, or return format. For a tool that likely performs a read operation, this is a major omission—the agent has no clue what happens when it's called.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is not conciseness—it's under-specification. While the brevity is technically efficient, it provides no actionable information, so the structure fails to serve the tool's purpose. Nothing is front-loaded because there is no content at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 9 parameters, no annotations, and no output schema, the description must supply substantial context, but it provides none. The agent lacks any understanding of input requirements, outputs, or how this tool integrates with the broader context system. This is completely insufficient for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 9 parameters with 0% coverage from the description. Required parameters like repository_id and target_commit are completely unexplained. No parameter names or purposes are elaborated, and the description adds zero detail to help the agent construct a correct call. With such a high parameter count, this is critically inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'business context list' is a near-verbatim restatement of the tool name. It fails to state what the tool actually does—what type of context it lists, what a 'business context' is, or how it differs from siblings like business_mapping_list or list_contexts. An agent cannot determine the tool's core function from this description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. With numerous sibling tools such as business_mapping_list, list_domains, and list_concepts, the complete lack of usage direction leaves the agent without any basis for selection. No intended scenarios or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 says nothing about what the tool does, side effects, requirements, or return behavior. The description is entirely uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is severe under-specification, not conciseness. A single uninformative phrase does not earn conciseness credit because no useful content is present to structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a complex nested schema, no output schema, and no annotations. The description must compensate but fails entirely, making the tool effectively unusable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameter meaning, but it provides none. Six parameters including nested objects (context, coverage) are wholly unexplained, leaving the agent unable to construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the tool name repeated: 'business coverage record' provides no verb, resource, or action. It is a tautology that fails to distinguish this tool from any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. No context, exclusions, or alternative tool references are given, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a description that only repeats the name, there is zero disclosure of behavior. The agent has no idea whether this is a write operation, whether it replaces or merges data, what side effects occur, or what the return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It lacks any structure or front-loaded information; every sentence (one sentence) fails to earn its place because it adds no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, a nested context object, 0% schema coverage, and no output schema, this description is wholly incomplete. An agent cannot determine how to structure the call, what the required fields mean, or what to expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain what scopes, domains, concepts, and context mean, but it says nothing. The parameters are completely unexplained, making it impossible to know what values are valid or how they relate to a business directory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'business directory batch upsert' merely restates the tool name without specifying what entities are being upserted (scopes, domains, concepts?) or what 'batch upsert' actually does. It is a tautology that provides no operational clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 siblings like business_contexts_batch_upsert or edge_batch_upsert. The description contains no context, prerequisites, or exclusions, leaving an agent without any basis to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only implies a read operation ('get') without stating any side effects, permissions, rate limits, or error behaviors. This is a major gap for a tool with 9 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is brief, this is severe under-specification rather than effective conciseness. It omits essential information and repeats the tool name, providing no structure or prioritized content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, no output schema, and a large sibling set), the description is wholly inadequate. An agent cannot correctly use this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds nothing about any of the 9 parameters. The agent is left to infer meaning from parameter names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'business directory get' simply rephrases the tool name, providing no verb-object specificity or distinction from sibling tools like business_directory_batch_upsert. It fails to convey what the tool actually does beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 any of the many sibling tools. There is no mention of context, prerequisites, or conditions that would lead an agent to select this instead of an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 such as whether this mutates data, requires permissions, or rebuilds indexes destructively. The description contains none of this, providing zero transparency for a presumably state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, this is under-specification rather than conciseness. There is no front-loading of meaningful constraints or alternatives; the text is just the name repeated, so it fails to earn its place as a useful addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, required fields, no output schema) and the absence of annotations, the description is completely inadequate. An agent cannot determine how to invoke this correctly without substantial external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter explanations. With 6 parameters (including required repository_id and target_commit), the agent has no idea what each parameter means or how they relate to the rebuild operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'business fts rebuild' is a near-verbatim restatement of the tool name. It adds no verb, resource, or scope clarification beyond what the name already implies, making it a tautology that fails to distinguish this tool from siblings like 'semantic_fts_rebuild' or 'index_rebuild'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or scenarios, leaving the agent to guess from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does not state whether the tool is a read, mutation, or validation action, what side effects occur, what authorization is needed, or what the response looks like. Zero behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short (three words) but this is under-specification, not effective conciseness. There is no useful content to be structured or front-loaded; it fails to convey the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 24 parameters, no output schema, and no annotations, the description is completely inadequate. An agent cannot determine valid parameter combinations, expected values, or the operation's semantics. Essential details are entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0% and 24 parameters (7 required), the description adds no meaning to any parameter. Even the required parameters like 'repository_id', 'target_commit', 'mapping_id', 'expected_version', 'status', 'actor', and 'evidence_refs' are completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a verbatim restatement of the tool name ('business mapping confirm'), providing no verb+resource specification, no scope, and no distinction from numerous siblings like 'semantic_confirm', 'confirm', or 'knowledge_confirm'. It is a pure tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. Given over 80 sibling tools including multiple confirm-like operations, the agent receives no routing guidance whatsoever.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, and the description says nothing about side effects, read/write behavior, permissions, or what operations are performed. For a tool with 24 parameters and no annotations, this is a total absence of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short, but this is under-specification, not conciseness. There is no front-loaded information, no sentence structure, and the entire description is a single redundant phrase that provides zero value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 24 parameters, 3 required, no output schema, and no annotations, the description is completely inadequate. An agent would have no idea what the tool does, how to call it, or what the required parameters mean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the 24 parameters. The description only repeats the tool name, leaving every parameter's meaning completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just the name repeated ('business mapping expand'). It provides no verb, resource, or action, and does not differentiate from siblings like business_mapping_search or business_mapping_get. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. No context, conditions, or exclusions are provided. With over 80 sibling tools, the lack of any routing info is a severe gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention whether the tool is read-only, what effects it has, what it returns, or any side effects. The description is empty of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. A single phrase that only repeats the name does not 'earn its place'; it wastes the opportunity to convey useful information. A well-formed conciseness would front-load key facts, which is absent here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (24 parameters, no output schema, no annotations, and a large set of siblings), the description is wholly inadequate. An agent has no way to know what parameters mean, what the return value is, or how this tool differs from similar ones. Completeness is essentially zero.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no explanation to any of the 24 parameters. The required parameters (repository_id, target_commit, mapping_id) and optional ones (limit, status, include_candidates, etc.) are entirely undocumented. The description provides no semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'business mapping get', which is simply the tool name restated. It provides no information about what the tool does, what a 'mapping' is, or what 'get' returns. It is a tautology with no explanatory value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 like business_mapping_search, business_mapping_expand, or business_mapping_list. The description offers no context, exclusions, or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses nothing: no side effects, no return behavior, no permissions, no edge cases. The description is empty of any behavioral content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, this is under-specification rather than conciseness. There is no useful information, so it fails to earn any 'efficiency' credit. A description should be concise but informative; this is simply absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no annotations, and no output schema, this description is grossly incomplete. An agent has no idea what inputs are required, in what format, or what the tool returns. It cannot be invoked correctly or even selected appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 10 parameters (3 required). There is no explanation of what repository_id, target_commit, context_id, or any other field represents beyond their names. The agent cannot infer parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly 'business mapping list', which merely restates the tool name. It does not state a verb, a resource, or any distinguishing scope. An agent cannot tell what this tool does beyond the literal words, and it does not differentiate from siblings like business_mapping_search or business_mapping_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. There is no mention of use cases, prerequisites, or exclusions. The agent is left entirely to inference from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral disclosure—no side effects, permissions, reversibility, or return behavior. With zero annotation coverage, the description carries full burden and fails entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is very short, which is usually good, but here it is under-specified to the point of being a near-tautology. Conciseness requires conveying essential information efficiently; this conveys none, so it earns a low score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 24 parameters, no output schema, and no annotations, a useful description is critical. This tool has none, making it completely inadequate for correct invocation without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 24 parameters, and the description adds no meaning to any parameter. The schema itself provides minimal hints (e.g., enums), but the description offers nothing to compensate for the large gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'business mapping reverse' merely repeats the tool name without any verb or resource explanation. It does not clarify what 'reverse' means or what operation is performed, so an agent cannot discern the purpose from this text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is absolutely no guidance on when to use this tool versus its many siblings like business_mapping_search or business_mapping_get. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It says nothing about read-only vs. mutating, side effects, rate limits, or return behavior. An agent would have no idea what calling this tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, but this is under-specification, not conciseness. It lacks any substantive content while the tool is complex (24 parameters). There is no front-loading of key information because there is no information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a large schema, no output schema, and no annotations, the description provides zero helpful context. An agent cannot determine the purpose, expected inputs, or outputs, making the tool effectively unusable without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 24 parameters. It does not explain what parameters like 'query', 'match', 'statuses', or 'expected_version' mean, leaving the agent to guess from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology—it merely restates the tool name with no verb, resource, or scope. It does not distinguish this tool from closely related siblings like 'business_mapping_list' or 'search_paths'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 any alternative. The description provides no context, prerequisites, or examples that would help an agent decide if this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries no behavioral information. It does not disclose side effects, safety profile, read/write nature, error conditions, or any operational details. The single repeating line adds zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than effective conciseness. It has no structure or front-loaded information; it merely echoes the tool name, providing no value to the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, required nested objects, and no output schema, the description is grossly incomplete. It fails to explain validation rules, return format, or even the basic intent. An agent cannot reliably invoke this tool based on this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of any parameter. While the schema reveals 'context' has repository_id and target_commit, and 'mappings' is an array, the purpose and format of these are completely unexplained. The description adds no meaning beyond field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is literally the tool name repeated: 'business mappings validate'. It does not state what the tool does, what validation means in this context, or what outcome the agent can expect. This is a classic tautology with no verb or resource elaboration, and there is no differentiation from the many sibling validators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 the many other validators (e.g., edge_validate, node_semantic_validate, business_candidates_validate). No scenario, prerequisites, or conditions are provided. An agent would have to guess which validator fits its task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. The description reveals nothing about what the tool does, what it returns, side effects, or prerequisites. It is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification, not conciseness. It has only a tautological phrase that earns its place by no informative value. A description this short would be acceptable only if the name were self-explanatory, which it is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, nested objects, enums, no output schema, no annotations), the description is drastically incomplete. An agent lacks even the most basic understanding of what to pass or expect. This is far below the minimum viable definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 13 parameters, 2 required, and 0% schema description coverage, the description must compensate. It provides no information about any parameter, not even confirming which are required. An agent cannot infer the meaning of context, operation_id, or any other field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: "check coverage" merely restates the tool name. It does not specify what entity is being checked, what coverage means here, or any verb+resource structure. An agent has no idea what this tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus its many siblings, such as check_coverage vs business_coverage_record or edge_validate. No context, alternatives, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It says nothing about what the tool retrieves, whether it is read-only, what kind of context it returns, or any side effects. The lack of any behavioral information is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than deliberate conciseness. There is no structure, no front-loading of key information, and no attempt to convey necessary details. Efficiency without content is not valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no output schema, and no annotations, the description is radically incomplete. An agent cannot determine what inputs to provide, what outputs to expect, or how this tool fits into the broader context retrieval workflow. The definition is not minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no semantic meaning to any of the 12 parameters. The required fields repository_id and target_commit are not explained, and the many optional fields like node_ids, direction, and traversal_policy are entirely undocumented. The description does not compensate for the missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'code context get' is a direct tautology of the tool name, offering no verb beyond 'get' and no clarification of what 'code context' means or what the tool does. It fails to distinguish this tool from many siblings like graph_context_get or dict_read, providing no unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is absolutely no guidance on when to use this tool versus alternatives. The description gives no context about scenarios, prerequisites, or when to choose a different tool among the extensive sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description gives absolutely no information about side effects, mutation, idempotency, permissions, or any other behavioral traits. The agent has no way to anticipate 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. There is no front-loaded information; it is just a single phrase that repeats the name. It does not earn its place as it provides no content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, required context) and the absence of an output schema, the description is completely inadequate. An agent would need far more than a name to call this tool correctly, and nothing is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions no parameters. With 7 parameters including nested objects and a required context object, the description adds no meaning whatsoever. The agent is left to figure out all parameter semantics from the schema alone, which is incomplete for nested structures.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a verbatim repeat of the tool name ('code facts commit') with no additional information. It fails to state what the tool does, what it operates on, or how it differs from any of the 70+ sibling tools. It is a pure tautology that provides zero value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. No context, no prerequisites, no exclusions, or recommended scenarios. An agent cannot determine if this is the appropriate tool for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description discloses no behavioral details whatsoever. The agent is left entirely unaware of side effects, return values, or operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, this is under-specification rather than conciseness. It is a tautological fragment that wastes the only opportunity to inform the agent, so it fails the 'earn its place' test.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, nested objects, and over 80 sibling tools, this definition is completely inadequate. Without any structured annotations or output schema, the description must carry the burden of explanation, and it carries none.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema itself provides no parameter explanations. The description adds nothing about the 7 parameters, including nested objects like 'nodes', 'evidence', and 'context', leaving the agent with no semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'code facts validate' merely restates the tool name without any verb, resource, or scope. It does not distinguish this from the many sibling validation tools (edge_validate, node_semantic_validate, business_candidates_validate, etc.), making it impossible to tell what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 any alternatives. No context about the intended workflow, prerequisites, or conditions for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description contributes nothing about side effects, authentication, rate limits, or what gets modified. With zero behavioral disclosure, the agent cannot anticipate any consequences of calling this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than conciseness. There is no content to structure or front-load; a single word that repeats the name is not a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 24 parameters, 7 required, enums, and no output schema, the description is completely inadequate. An agent would have to guess at the semantics of every parameter and the expected behavior, making correct invocation virtually impossible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. With 24 parameters and 0% schema description coverage, the description fails to compensate for undocumented parameters. Required fields like repository_id, target_commit, mapping_id, expected_version, status, actor, and evidence_refs are entirely unexplained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. No conditions, no exclusions, no mention of related tools. The agent is left completely in the dark about which 'confirm' operation this is among the many confirm-like siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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, yet it fails to disclose any behavior, side effects, prerequisites, or return characteristics. There is no contradiction with annotations because none exist, but the description provides nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is concise (two words), this is not appropriate conciseness but severe under-specification. It omits essential information that should be present, making it unhelpful rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 24 parameters, no schema coverage, no output schema, and a tautological description, the tool is completely incomplete. An agent has no way to correctly invoke this tool or understand its function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no documentation for any of the 24 parameters. The description offers no parameter explanations, making it impossible for an agent to understand what values to supply for repository_id, target_commit, or the 22 optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'confirmation audit' is a tautology that simply restates the tool name without a verb or resource, providing no indication of what the tool actually does. It is indistinguishable from the name itself and gives no specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool, what conditions select it over alternatives, or any exclusions. The description contains zero usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits such as side effects, permissions, idempotency, or failure modes. The description offers nothing on these aspects. With 13 parameters including an idempotency_key and expected_parent_snapshot_id, behavioral transparency is critical and entirely missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It contains no structured information, no front-loading of key details, and no useful content. A single sentence that adds no information is not concise; it is inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool—13 parameters, two required, nested objects, no output schema, and no annotations—the description provides essentially nothing. An agent cannot correctly invoke this tool based on the provided definition. The description is completely insufficient for contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter has any explanatory text in the schema. The description does not compensate by explaining any of the 13 parameters, their relationships, or typical values. For example, 'context' is required and has nested fields like repository_id and target_commit, but the description gives no hint about how they are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly 'detect conflicts', which restates the tool name without any additional detail. It fails to specify what kind of conflicts, what resource or operation it applies to, or what the output is. This is a pure tautology with no informational value for an agent deciding whether to call it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool versus any of the many sibling tools. There is no mention of scenarios, prerequisites, or alternatives. An agent has no basis to distinguish detect_conflicts from tools like edge_validate or code_facts_validate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It discloses nothing—no read-only hints, no effects, no side behaviors, no error conditions. A complete absence of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is superficially concise, but it is under-specified to the point of uselessness. This is not conciseness; it is a failure to include necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, 2 required, and no output schema, the description is completely inadequate. An agent has no way to understand how to construct a valid request or what to expect in response. This is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameters, but it does not mention any of the 12 parameters. No meaning is added beyond the schema, and the schema itself is largely opaque with generic names like 'scope_id' and 'context_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'dict read' is a tautology that merely restates the tool name. It fails to state what the tool does, what resource it operates on, or how it differs from any sibling tool. An agent cannot determine the tool's purpose from this text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. The description offers zero strategic information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It reveals nothing about side effects, permissions, idempotency, concurrency, error behavior, or whether the operation is destructive. The term 'write' hints at mutation, but no details are offered. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is not conciseness; it is under-specification. A one-sentence description could be concise yet informative, but 'dict write' contains no substance. There is no structure, no front-loading of key information, and no attempt to explain the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters (4 required), no output schema, no annotations, and no explanation, the description is completely inadequate for an agent to understand how to invoke the tool correctly. The context signals indicate high complexity and zero schema coverage, making the description's lack of detail a critical failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does 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 12 parameters. It provides no explanation of any parameter. Even the required parameters (repository_id, target_commit, entity_type, payload) are ambiguous without further context. Fields like operation_id, snapshot_id, and idempotency_key are completely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'dict write' is a tautology that merely restates the tool name with a space. It provides no information about what the tool does, what entities it operates on, or how it differs from the many sibling tools. There is no verb, resource, or outcome described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. Given the large sibling set (e.g., edge_batch_upsert, business_mappings_batch_upsert), an agent has no way to determine if dict_write is appropriate for a given task. No exclusions, prerequisites, or fallback tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates no effects, requirements, side effects, or expected output. For a tool named 'validate', it's unclear whether it's read-only or mutating, and no clarity is offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the text is extremely short, this is under-specification, not deliberate conciseness. There is no structure, and the one-word phrase does not earn its place because it adds no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, nested objects, and no output schema, the description is completely inadequate. An agent cannot safely call this tool based on the provided information; critical details about inputs, validation logic, and return values are entirely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero information about any of the six parameters. The schema defines structure but no semantics; the description fails to compensate, leaving required fields like 'edges' and 'context' completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'edge validate' is a tautology—it merely repeats the tool name with a space. It does not state a specific verb, resource, or scope, and provides no differentiation from sibling tools like edge_batch_upsert or node_semantic_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description does not mention any context, prerequisites, or exclusions, leaving the agent with no basis to decide whether to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It does not state whether the tool is read-only, what side effects it has, or what the response shape might be. The description contributes nothing beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than concise effectiveness. Two words provide no structural benefit; it is not front-loaded with useful information because there is no information at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, no annotations, and a terse description, the tool is completely under-documented. An agent cannot reasonably determine how to call this tool correctly or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters. The sole required parameter, evaluation_run_id, is not described, leaving the agent without any understanding of what values are valid or what it represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'evaluation get', which is a tautology of the tool name. It does not state what entity is being fetched, what the tool does, or how it differs from sibling tools like evaluation_golden_set or evaluation_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description provides no context about the intended use case, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 provides zero information about side effects, required permissions, data mutation, or return behavior. The phrase 'golden set' suggests a data structure, but the tool's behavior is entirely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It contains no useful information and fails to front-load any meaningful content. A description of six words that repeats the name offers no structural value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, the description is fundamentally inadequate. An agent would have no idea what inputs to provide, what outputs to expect, or what side effects might occur. The description does not come close to enabling correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters. Despite 7 parameters including cases (required), actor, request_id, etc., the description provides no hints about their meaning, format, or relationships. The description fails to compensate for the absent schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'evaluation golden set' is a tautology of the tool name. It lacks any verb or action to indicate what the tool does. There is no mention of creating, retrieving, validating, or manipulating a golden set, and it does not distinguish itself from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as evaluation_run or evaluation_get. The description gives no context, no prerequisites, and no explicit or implied usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description detail, the agent has zero transparency into side effects, permissions, or return behavior. The description adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one word, which is extremely concise, but it is under-specified rather than appropriately concise. There is no structure, no front-loading of key constraints, and no explanatory value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, a required enum, and no output schema, this description is wholly inadequate. It does not explain the purpose, the required fields, or the format options, leaving the agent unable to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does 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 any parameters or their meanings. With 9 parameters including 4 required ones, the description leaves the agent completely unassisted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The sibling list includes many tools like 'push', 'publish', and 'ingest', but the description gives no indication of selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no descriptive content, behavioral traits are completely undisclosed. The agent cannot infer side effects, read/write nature, permissions, or return behavior from the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is gross under-specification rather than conciseness. A single fragment fails to convey any operational detail and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, this description is completely inadequate for an agent to select and invoke the tool correctly. All meaningful context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 8 parameters, and the description adds no meaning beyond parameter names. With required parameters like repository_id, target_commit, and node_ids, the agent gets no help on formats, relationships, or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'get nodes' is a near-verbatim restatement of the tool name, providing no verb+resource specificity. It does not distinguish this tool from siblings like node_batch_get or get_edges, and gives no hint of what nodes are being retrieved or under what conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description offers no context, prerequisites, or exclusions, leaving the agent entirely without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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, yet it says nothing about side effects, required permissions, return format, pagination, or node/edge filtering behavior. The tool appears to be a read operation, but this is never stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, this is under-specification rather than conciseness. For a tool with 14 parameters and no annotations, a single tautological phrase is grossly insufficient. It fails to front-load any operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (14 parameters, 3 required, no output schema, no annotations) and the description covers none of the necessary context: parameter semantics, expected output, relationship to sibling tools, or operational constraints. It is completely inadequate for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 14 parameters with 0% schema description coverage, and the description adds zero information about their meaning. For example, 'depth', 'include', 'direction', 'edge_types', and 'stop_sub_kinds' are all undefined, leaving the agent to infer semantics purely from names, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'graph context get' is a pure tautology that merely restates the tool name. It provides no verb-resource structure, no indication of what the tool actually does (e.g., retrieves a subgraph for a commit), and no differentiation from siblings like code_context_get or traverse_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 like code_context_get or search_nodes. No context, prerequisites, or exclusions are provided; an agent must guess the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears all responsibility for behavioral disclosure. It explains nothing about side effects, permissions, or operational details. Without annotations, this total absence of behavioral information is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically concise (one word), but it is under-specified rather than efficiently structured. It omits essential information, making it a placeholder rather than a useful definition. This is not the kind of conciseness that earns credit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is wholly inadequate. An agent cannot determine the tool's purpose, invocation requirements, or expected behavior. This is an incomplete definition on every front.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 0% description coverage, yet the description explains none of them. It does not clarify what 'repository_id' means, what the optional fields like 'actor' or 'request_id' signify, or how they affect the call. The description adds nothing beyond the raw schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 or how it differs from alternatives. The description contains no context, prerequisites, or contrast with sibling tools like 'status' or 'job'. It gives the agent no basis for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects, permissions, or output. It says nothing about what happens during an index rebuild, whether it's destructive, or what the response contains. For a potentially heavy operation, this is a complete void.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words) but this is under-specification, not conciseness. It contains no useful information structure – no front-loaded scoping, no alternative routing. The minimalism offers no value to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, no annotations, and a vague purpose, the description is fundamentally incomplete. An agent cannot determine when to call this tool, what inputs are truly needed, or what consequences the call has. It is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 7 parameters (only repository_id required). The description does not explain any parameter's meaning, format, or relationship to the operation. With such low coverage, the description was expected to compensate, but it adds nothing beyond the schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'index rebuild' is a direct restatement of the tool name 'index_rebuild' – a noun phrase with no verb. It does not state what the tool actually does (e.g., rebuild an index for a repository) and offers no distinction from sibling tools like semantic_fts_rebuild. This is a tautology, matching the 'process' example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. No mention of prerequisites, conditions, or when not to use it. The description provides no context for selection among 90+ siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects, requirements, or return behavior. It discloses nothing, leaving the agent completely blind to whether this is a read, write, or destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise writing. A single word provides no structured or scannable information. While it is technically brief, it fails to satisfy the requirement that every sentence earns its place, as there is no meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters including nested objects and enums, no output schema, and no annotations, this description is drastically incomplete. An agent has no idea what inputs to provide, what the tool returns, or what side effects may occur. It is far below the minimum viable definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter relationships or purpose. It adds nothing about the 13 parameters, including required fields like context and operation_id, or the action enum (retry/resume/cancel). Without description, the agent cannot infer intended usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever on when to use this tool, what it does, or how it differs from the many sibling tools like job_cancel or job_resume. The description offers zero context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description reveals nothing about side effects, idempotency, required permissions, or what happens after cancellation. No behavioral information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, but this is under-specification, not conciseness. There is no information to structure or front-load. It fails to provide even minimal useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, 2 required, no annotations, and no output schema, the description is completely inadequate. An agent cannot determine how to correctly invoke this tool or interpret its behavior. The description is essentially non-existent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation of any of the 13 parameters. Required fields like context and operation_id are completely undocumented, as are enums like action. The description adds zero semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'job cancel', which simply restates the tool name. It provides no verb-resource specificity and does nothing to distinguish it from siblings like job_resume or status. This is a pure tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention any context, conditions, or exclusions. An agent would have no idea when to invoke job_cancel over job_resume or job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description gives zero information about side effects, permissions, mutation vs. read-only nature, or return behavior, leaving the agent completely blind.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. While there is no wasted text, the single token provides no useful information, so it does not earn credit for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters (2 required), no output schema, nested objects, and zero annotation coverage, the description is completely inadequate. An agent cannot correctly call this tool with only the phrase 'job resume'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description mentions none of the 13 parameters. With no explanation of how parameters like 'action', 'context', or 'threshold' affect behavior, the agent has to guess from names and types alone, which is insufficient given the complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'job resume' is a direct restatement of the tool name, providing no verb, resource, or distinguishing detail. It fails to convey what the tool actually does, leaving the agent to infer from the name alone, which is ambiguous given the 'resume' action could mean resuming a job or retrieving a resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 like job_cancel or status. No context about appropriate scenarios, prerequisites, or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 discloses nothing: no side effects, no read vs. write nature, no permissions, no return behavior. The agent is left completely in the dark about what calling this tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified to the point of being nearly empty. This is not conciseness (which implies dense, purposeful wording) but severe omission. While short, it forfeits the opportunity to communicate anything meaningful, so it fails the structure/front-loading test entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 optional parameters, no output schema, and no annotations, the description is completely inadequate. There is no information about the operation's purpose, expected inputs, return values, or side effects. An agent cannot reasonably call this tool with any confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are no parameter descriptions in the schema. The description does not compensate at all—it mentions no parameter names, types, or meanings. With 4 parameters (request_id, tool_version, schema_version, timeout_seconds) and zero explanatory text, the agent cannot know what values to supply or why.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is literally the tool name repeated: 'knowledge command status'. It is a pure tautology that states no verb, resource, or operation. It gives an agent no clue what the tool does or how it differs from any of the ~70 sibling tools, many of which also relate to status (e.g., 'status', 'job_status', 'skill_status').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever about when to use this tool versus alternatives. The description does not even imply a use case, let alone specify conditions or excluded scenarios. An agent would have to guess which of the many status-like tools to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It reveals nothing about what happens when the tool is invoked, what side effects occur, what permissions are required, or what the response format is. For a tool that implies a confirmation action, this is a significant gap, leaving the agent completely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which might appear concise, but it lacks any substantive content. This is under-specification rather than conciseness; the single phrase adds no value and does not front-load any useful information. A minimal but helpful description would at least state the tool's purpose and key behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—9 parameters, no annotations, no output schema—the description is woefully incomplete. It provides no context about the operation, when to use it, what the expected inputs mean, or what the agent should expect as a result. This is drastically insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 9 parameters with 0% description coverage, and the description adds nothing. It does not explain the meaning of critical fields like knowledge_id, operation_id, or evidence_refs, nor does it describe how parameters interrelate. The description is entirely unhelpful for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'knowledge confirm', which repeats the tool name and gives zero information about what the tool actually does. It does not state a verb-resource pair or differentiate from siblings like knowledge_reject or confirm. This is a textbook tautology, providing no additional substance beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 knowledge_reject, confirm, or semantic_confirm. The description offers no context, prerequisites, or exclusion criteria. An agent has no basis to decide if this is the right tool for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says only 'knowledge generate' — no mention of side effects, mutability, permissions, rate limits, or return behavior. For a tool that likely creates or updates knowledge, this is a serious gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one word), but this is under-specification, not effective conciseness. It does not front-load any useful information; every useful sentence is absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 params, 5 required, no schema descriptions, no output schema), the description is completely inadequate. An agent cannot correctly invoke this tool without guessing at parameter formats and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 11 parameters with 0% description coverage, and the tool description provides zero clarification. Parameters like 'mapping_ids', 'source_revision', and 'operation_id' are completely unexplained. The description adds no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is literally 'knowledge generate' — a tautology that restates the tool name without adding any verb+resource specificity. It does not distinguish from siblings like knowledge_confirm or knowledge_reject, and gives no clue about what 'generate' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is absolutely no guidance on when to use this tool versus any of the dozens of siblings. No context, no exclusions, no mention of alternatives. An agent has no way to decide whether to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It discloses nothing about side effects, permissions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification, not conciseness. It fails to earn its place by adding any meaningful content; it is merely a name repeat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no description, the tool is essentially unusable for an agent. Everything an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 9 parameters with 0% description coverage, and the description adds nothing about any parameter. The agent is left completely uninformed about what each parameter means or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'knowledge reject' simply repeats the tool name without stating what the tool does. It is a tautology that provides no verb, resource, or distinction from any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 or when to prefer an alternative. With over 80 siblings, the absence of any usage context is a critical gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 simply says 'list concepts' with no information about side effects, read-only nature, rate limits, pagination, or return format. The agent has no idea what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short (two words), this is not effective conciseness—it is under-specification. There is no front-loaded key information; the description provides no value whatsoever. A concise description of one useful sentence would be far better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 9-parameter tool with no output schema, no annotations, and no documentation. The description is entirely inadequate for an agent to call it correctly. It does not explain what a concept is, how the parameters relate, or what the return value looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 9 parameters and 0% description coverage. The description adds no meaning to any parameter. The agent cannot infer what 'domain_id', 'concept_id', 'snapshot_id', 'request_id', or 'tool_version' mean in this context. The description completely fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list concepts' is a tautology that simply restates the tool name. It does not specify what a 'concept' is, what resource is being listed, or how it differs from sibling listing tools like list_scopes, list_domains, or list_contexts. An agent cannot distinguish this tool from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 or when to prefer alternatives. No context, prerequisites, or examples are provided. The agent is given zero help in selecting this tool over the many similar list/read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses nothing: no mention of side effects, read-only vs. mutating behavior, rate limits, pagination, or what the returned data represents. This is essentially a black box with no behavioral information at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. It lacks any informative content; a single verb phrase does not earn its place as it provides no value. While brevity is generally positive, here it is taken to an extreme that renders the description useless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no annotations, this description is completely inadequate. The agent cannot infer the required inputs (repository_id, target_commit) or what the output will be. Given the complexity implied by the schema and the presence of many similar sibling tools, the description is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 9 parameters are explained by the schema descriptions. The tool description adds absolutely nothing about the meaning, format, or relationships of parameters like scope_id, domain_id, concept_id, request_id, snapshot_id, etc. With such a high parameter count and zero coverage, the description is entirely insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'list contexts', which is a tautology of the tool name. It restates the name without providing a verb for any specific action, resource, or scope. No distinction is made from sibling tools like list_scopes, list_domains, or list_concepts, leaving the agent unable to know what a 'context' actually is or how this tool differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description is a single phrase with no context, no mention of use cases, prerequisites, or conditions under which another tool (e.g., list_scopes or graph_context_get) would be more appropriate. The agent is left with zero routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 discloses nothing — no side effects, permissions, or limitations. An agent cannot infer whether this is read-only, mutating, or what happens on execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It does not front-load any useful information, and its brevity comes at the cost of all meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 3 required, no output schema, no annotations), the description is entirely inadequate. An agent would have to guess at every aspect of behavior, parameter usage, and return value, making correct invocation highly uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero parameter information. With 10 parameters including required ones like repository_id, snapshot_id, and source_revision, the description fails to explain their meaning or relationships. The description does nothing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'mining discover' is a tautology that merely repeats the tool name. It provides no information about what the tool does, its scope, or its intended resource. There is no distinction from sibling tools like mining_run or discover-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description does not mention any context, prerequisites, or exclusions, leaving agents without any basis to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure, yet it states nothing about side effects, mutation, read-only nature, or any operational traits. The description is entirely empty of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, this is under-specification rather than conciseness. The single phrase provides no structural benefit; it fails to front-load any useful information because it contains none.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 10 parameters, 4 required, and no output schema, this description is completely inadequate. It provides no context about return values, side effects, or operational expectations, making it impossible for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 10 parameters with 0% coverage, and the description adds no meaning to any parameter. Required fields like repository_id and snapshot_id remain unexplained, leaving the agent to guess their formats or purposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology, repeating the tool name 'mining run' with no verb or resource specification. It provides no distinction from any sibling tool and gives an agent no reason to pick it over alternatives like mining_discover or snapshot_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance exists on when or why to use this tool. There is no mention of prerequisites, context, or comparison to sibling tools, leaving the agent with zero direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states no effects, side effects, safety implications, or operational constraints. It is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is not conciseness—it is under-specification. No useful information is front-loaded, and the single phrase adds no value. It fails to earn its place semantically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and a large sibling set that includes similar batch operations, this description is grossly incomplete. It provides virtually nothing an agent needs to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter meaning. With 8 parameters (including required ones like repository_id, target_commit, node_ids), an agent has no clue what these fields represent or how to populate them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'node batch get' simply restates the tool name, offering no verb-resource specificity or differentiation from sibling tools like 'get_nodes' or 'node_semantic_batch_upsert'. It is a tautology and gives an agent no understanding of what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. The description provides no context, no prerequisites, and no exclusions, leaving an agent to guess which of the many similar batch/get tools to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits (e.g., mutation, idempotency, schema constraints). It provides none, only restating the name. The agent has no idea about side effects, concurrency, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not concise value. It contains only five words with zero information content beyond the name. There is no structure or front-loading of constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a batch upsert tool with nested objects, multiple metadata fields (idempotency_key, tool_version, etc.), and no output schema, the description is grossly insufficient. An agent would be completely lost on how to construct a valid call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters, the description must compensate by explaining parameters like 'context' and 'semantics'. It does not even mention them. The agent cannot infer what 'semantics' items should contain or how 'context' is structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a verbatim repetition of the tool name ('node semantic batch upsert') with no additional context. It fails to state what the tool does beyond the name itself, and does nothing to distinguish it from siblings like edge_batch_upsert or business_mappings_batch_upsert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 the many related batch operations (edge_batch_upsert, business_contexts_batch_upsert, etc.). No conditions, no alternatives, no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals nothing about side effects, required permissions, return format, or error behavior. For a tool that appears to perform validation semantics, there is zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), but this is under-specification rather than concise writing. A good concise description still conveys meaning; this one adds no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (2 required) with nested objects, no annotations, and no output schema, the description is completely inadequate. An agent cannot determine how to construct the context object or what the semantics array should contain, nor what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description adds no information about the required 'context' and 'semantics' objects, nor about the optional parameters. The agent is left entirely in the dark regarding parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is literally 'node semantic validate', which merely restates the tool name. It provides no verb-object structure, no resource, and no differentiation from sibling tools like code_facts_validate or edge_validate. This is a tautology, not a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 the many sibling validation tools (e.g., code_facts_validate, edge_validate, business_mappings_validate). No conditions, exclusions, or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It fails entirely—no mention of side effects, required permissions, failure modes, or response behavior. The agent has no information about what happens when this tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than conciseness. There is no structure, no front-loading of critical information, and no sentences that earn their place—just a single word that repeats the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters, multiple required fields, nested objects, and an enum, the description is utterly incomplete. There is no output schema to compensate, and the minimal text fails to convey any operational or contextual details necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 0% of the parameters with descriptions, and the tool description adds nothing. There are 13 parameters including nested objects and required fields, yet the agent receives no explanation of their meaning, relationships, or how to construct valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 any alternative. The description gives no context about prerequisites, conditions, or intended scenarios, leaving the agent completely without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description, the agent has zero information about side effects, permissions, idempotency, or any behavioral traits. The description adds nothing beyond the bare existence of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is technically short, this is under-specification rather than conciseness. A single word that repeats the tool name carries no information and fails to earn its place as a description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters, 6 required, nested objects, and no output schema, this description is completely inadequate. There is no explanation of what pushing means, what the target object represents, how dry_run behaves, or what the operation returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 13 parameters with 0% description coverage, and the tool description provides no parameter meanings. The agent is left to infer everything from parameter names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance whatsoever on when to use this tool versus any of the 80+ siblings. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description, there is zero disclosure of behavioral traits. An agent cannot tell whether this is read-only, mutating, network-bound, or what side effects it might have. The description provides no value beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It front-loads nothing useful; a single word provides no information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, 5 required, and no output schema or annotations, the description is drastically incomplete. An agent has no idea what the tool returns, what inputs are needed beyond their names, or what edge cases exist. This is entirely inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining the 13 parameters, but it explains nothing. Required parameters like 'query', 'repository_id', and 'snapshot_id' have no semantic meaning added beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever about when to use this tool versus the dozens of alternatives in the sibling list. The description contains no context, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It reveals nothing about side effects, return format, required permissions, or failure modes. The word 'read' implies non-destructiveness, but even that is unstated explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It contains no useful information and fails to front-load any meaningful content. A single phrase that merely repeats the name is not an appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no annotations, and no output schema, the description is completely inadequate. An agent cannot safely invoke this tool without knowing what a query trace is, what data it returns, or how parameters interplay. This is far from complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It mentions none of the six parameters, leaving query_trace_id, snapshot_id, request_id, etc. entirely undefined. The agent has no clue which are essential or how they relate to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a direct restatement of the tool name ('query trace read') with no additional context. It provides no verb-resource structure or any differentiation from sibling tools like dict_read or evidence_get. An agent cannot determine what a 'query trace' is or what reading it entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. No mention of contexts, prerequisites, or exclusions. Given the large set of siblings with similar 'read' prefixes, the absence of any routing information leaves the agent guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description gives zero behavioral information. There is no mention of side effects, required permissions, result semantics, or limitations. The tool is a black box.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but this is under-specification rather than effective conciseness. A single two-word phrase does not structure information for an agent; it provides no front-loaded details or useful structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (24 parameters, no output schema, no annotations), this description is woefully incomplete. An agent cannot infer how to correctly invoke this tool or interpret results. It needs a full rewrite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 24 parameters and 0% schema description coverage, the description carries the full burden of explaining parameters but offers nothing. The parameter names like 'edge_id', 'node_id', 'statuses', 'max_steps' are ambiguous without context, and the description does not clarify their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'search paths' which simply restates the tool name without a verb or resource. It does not explain what the tool does—whether it searches for paths between nodes, lists paths, etc. It fails to distinguish from siblings like find_paths or traverse_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 like find_paths or search_nodes. The description provides no context about typical use cases or conditions that would route an agent here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 reveals nothing about side effects, whether confirmation is idempotent, whether it writes state, or what failure conditions exist. For an operation that presumably modifies confirmation state, this is a complete gap. However, there is no contradiction with annotations since none are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically brief (two words), but it is under-specification rather than conciseness. There is no substance to evaluate for structure or front-loading—it is simply a placeholder that repeats the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, a nested object, no annotations, no output schema, and a semantic confirmation purpose that must be distinguished from at least three similarly named siblings, the description is completely inadequate. An agent has no way to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 7 parameters including required 4 (context, semantic_id, confirmed_by, expected_version), plus a nested object. The description provides zero insight into what parameters mean, how they relate, or why expected_version is required. A nested context object with repository_id and target_commit adds complexity that the description fails to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'semantic confirm', which is a tautology of the tool name. It provides no verb, no resource, no scope, and no differentiation from similar siblings like 'confirm', 'knowledge_confirm', or 'business_mapping_confirm'. An agent cannot determine what this tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains no guidance on when to use this tool versus any of the many confirmation-related siblings. Given the presence of several similarly named tools (business_mapping_confirm, knowledge_confirm, semantic_term_search), this ambiguity is critical and unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. The word 'rebuild' implies an index-construction operation, but the description does not state whether it is destructive, how long it takes, what data it operates on, or any side effects. This is completely insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. There is no useful information in the text, so the brevity is not a virtue. It does not front-load any critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 2 required, no annotations, no output schema), the description is grossly incomplete. It fails to provide any context about the tool's purpose, behavior, parameters, or relationship to siblings. An agent could not use this tool correctly based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to any of the 6 parameters. The required parameters repository_id and target_commit are not explained, and the optional parameters (request_id, tool_version, schema_version, include_statuses) are entirely undocumented. The description offers zero value in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'semantic fts rebuild' is a tautology that simply restates the tool name without explaining what the tool does. It fails to identify the verb (rebuild), the resource (semantic full-text search index), or any scope. It does not differentiate from siblings like business_fts_rebuild or index_rebuild.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. An agent has no information about the intended use case, prerequisites, or context in which this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden of disclosing behavior. It says nothing about side effects, return format, performance, or constraints. The tool may be a read-only search or may trigger something; nothing 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification, not concise richness. It offers no front-loaded value and does not earn its place as a useful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, 0% schema coverage, no annotations, and no output schema, the description is nonexistent. An agent cannot safely or correctly invoke this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the 11 parameters (including required ones like repository_id, target_commit, terms). Required parameters are completely unexplained, leaving the agent guessing about identifiers, formats, and semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is a tautology: 'semantic term search' merely restates the tool name without saying what it does, what resource it operates on, or how it differs from siblings like 'search_nodes' or 'query'. Specific verb and resource are absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information on when to use this tool, what problem it solves, or when to prefer an alternative. Given 55 sibling tools, the agent has no basis to select this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about side effects, read-only vs. destructive nature, authentication needs, rate limits, or what the response contains. For a status-checking tool, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), but this is under-specification rather than concise efficiency. It burdens the agent with guessing the tool's purpose and parameters. The word 'status' is repeated from the name, adding no information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no output schema, and no annotations, the description is grossly inadequate. It provides no sense of return value, error conditions, or operational context. Given the sibling tools that suggest a broader workflow, this description leaves an agent fundamentally unable to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does 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 any of the four parameters. The schema provides only names and types, not meaning or usage context. An agent must guess what 'job_id' or 'request_id' refer to and how they relate to the skill status operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'skill status' is essentially a restatement of the tool name. It provides no verb, no resource, and no indication of what action is performed. It does not distinguish this tool from siblings like 'status' or 'job' — an agent cannot tell what 'skill status' actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. Sibling tools named 'status', 'job', and 'knowledge_command_status' suggest overlapping functionality, but the description gives no context, no exclusions, and no mention of prerequisites or preferred conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 says nothing about side effects, return values, access requirements, or any operational characteristics, leaving the agent completely uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It provides zero informative content, so it fails to earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no behavioral description, the context is completely incomplete. An agent cannot determine what inputs are required, what operation is performed, or what the result will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for any of the 8 parameters. The tool description offers no compensation, leaving all parameter meanings undefined. The only hint is the repository_id required field, but no explanation of what it represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'snapshot catalog' is a tautology that merely restates the tool name. It lacks a specific verb, resource, or any indication of the operation performed, making it impossible for an agent to infer the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like snapshot_switch or snapshot_cleanup. No context, prerequisites, or usage scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, idempotency, or impact on snapshots. The agent has zero information about what happens when the tool is called, whether it is destructive, or what resources it affects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but this is under-specification, not conciseness. While it is only two words, it fails to earn its place by providing any actionable information. The lack of structure or front-loaded content means an agent gains nothing from reading it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an 8-parameter tool with no output schema, no annotations, and zero schema coverage, this description is severely incomplete. An agent cannot possibly know what inputs are expected, what the tool does, or what to expect in return. The description is wholly inadequate for any invocation scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 8 parameters and 0% schema coverage, the description adds no meaning to the parameters. The schema itself provides only names and types with no descriptions. The required parameters 'repository_id', 'actor', and 'permission_scope' are left entirely undocumented, and the description offers zero clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'snapshot cleanup' is a tautology that merely restates the tool name. It does not specify any verb-resource relationship, what is being cleaned, or what the operation entails. With no additional context, an agent cannot distinguish this from any other cleanup operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 any of the 70+ sibling tools. The description provides no context, prerequisites, or exclusions, leaving the agent completely in the dark about appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description offers nothing: no statement of side effects, permissions, reversibility, or return behavior. An agent cannot know whether this is a read, write, or destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than effective conciseness. It is a single vague phrase that adds no value and fails to address any critical information. It earns a 2 for not being verbose but is far from a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, no output schema, and a complex domain (snapshot management), the description is completely inadequate. An agent cannot safely or correctly invoke this tool. It lacks every piece of context needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the 6 parameters. With zero guidance on request_id, snapshot_id, target_commit, etc., an agent has no idea what values are expected or how they relate to the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'snapshot switch' is a tautology that merely restates the tool name. It provides no verb, resource, or scope. An agent cannot infer what the tool does, what it operates on, or how it differs from sibling tools like snapshot_cleanup or snapshot_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus any alternative. There is no context, prerequisites, or exclusion criteria. With 80+ sibling tools, an agent has no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior — side effects, return values, prerequisites, or state changes. The two-word description reveals nothing about what happens when the tool is called. With a mutation-capable name like 'stale event' and a separate read sibling, behavioral disclosure is critical and entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
This is under-specification, not conciseness. Two words carry zero usable information for a 5-parameter, schema-less tool. While brevity is generally positive, the description is too short to earn its slot and adds no value beyond the name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, nested objects, no annotations, no output schema, and a confusing sibling landscape, the description is radically incomplete. An agent has no information about what the tool returns, when to call it, or how the parameters should be constructed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters including a nested object with required fields (`repository_id`, `target_commit`). The description adds no meaning to any parameter; an agent must guess what `context`, `operation_id`, `schema_version`, etc. represent and how they interrelate. The description completely fails to compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is literally "stale event" — a pure tautology that restates the tool name without a verb or resource. It provides no indication of what the tool does, and it does nothing to distinguish this tool from the sibling `stale_event_read`, leaving the semantic relationship between the two entirely unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever about when to use this tool versus alternatives. Given that a sibling `stale_event_read` exists, the agent has no way to know which one to invoke for a given task, and nothing in the description disambiguates them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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, and it fails entirely. It does not mention effects, read-only vs. mutation, permissions, pagination, return format, or any side effects. The tool name implies a read but nothing is substantiated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically brief, but this is under-specification rather than conciseness. There is no useful content to be concise about. A placeholder of a few words does not earn credit for efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, many siblings), the description is completely inadequate. It provides no information about what the tool does, what input means, or what the output will be. An agent cannot possibly call this tool correctly based on the current definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to any of the 10 parameters. Required 'repository_id' and optional fields like 'snapshot_id', 'operation_id', 'page_token' have no explanation. The agent cannot infer parameter usage or format from either schema or description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'stale event read' is a tautology that simply restates the tool name. It does not specify a verb, resource, or any distinctive behavior. There is no clarification of what constitutes a 'stale event' or what the read operation entails, leaving the agent with no understanding of the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 the many siblings (e.g., 'stale_event', 'evidence_verify', 'snapshot_catalog'). No context, prerequisites, or exclusions are provided. The description offers zero usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. There is no indication of whether the tool is read-only, what it returns, or how it behaves. The description fails to carry the burden of behavioral disclosure for a tool that appears to retrieve status information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is trivially short, but this is under-specification, not conciseness. It omits all essential information. A single word cannot be considered well-structured or compact when it carries no value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, a nested required object, and no output schema, the description is completely inadequate. Given the complexity of the input schema and the absence of annotations, the description provides no guidance on how to construct a valid call or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds nothing. The required 'context' object with nested fields like repository_id and target_commit is completely unexplained. The schema itself provides no descriptions, and the tool description does not compensate, leaving all parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 the many sibling tools like 'job_status', 'skill_status', or 'knowledge_command_status'. No context, alternatives, or exclusions are given, so the description offers no help in selecting among the status-like tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, but it reveals nothing about side effects, return format, performance implications, or required permissions. The word 'traverse' implies reading, but no explicit statement is made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than purposeful conciseness. No value is delivered beyond the name; a tool with 15 parameters needs substantive explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 15 parameters, no output schema, and no annotations, this description is wholly inadequate. It does not even hint at the tool's core functionality, performance budgets (edge_budget, node_budget), or traversal direction semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 15 parameters. The description provides zero information about parameter meaning, relationships, or constraints, leaving the agent to guess from names alone (e.g., what is the difference between node_id, from_node_id, to_node_id, start_node_ids?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name ('traverse graph') without any additional specificity. It does not identify the resource being traversed, the nature of the graph, or how it differs from siblings like find_paths and search_paths. This is a pure tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool instead of alternatives. With 80+ sibling tools, the absence of any usage context leaves the agent unable to make an informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update' implies mutation but gives no details on side effects, permissions, reversibility, or response. The tool's behavior is completely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word, which is under-specification rather than concise structure. There is no information density or useful front-loading; it merely repeats the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 parameters, 7 required, nested objects, no output schema, and no description. The description is wholly inadequate for an agent to call this tool correctly or to distinguish it from the many sibling tools in the same domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter meaning. With 11 parameters, 7 required, including nested objects like context and changes, an agent has no idea what values to supply or what the parameters represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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, what scenarios it fits, or which alternatives to prefer. The description contains zero context about its intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It merely states 'batch upsert', implying mutation, but gives no information about side effects, idempotency, error handling, rate limits, or whether the operation is reversible. It does not reveal anything about what gets modified or what consequences the agent should expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is superficially concise, but it is under-specified rather than efficiently informative. It does not front-load any useful context and lacks substance that would help an agent. This is not genuine conciseness but rather an absence of content, so it does not meet the criteria for a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects, no output schema, no annotations), the description is drastically inadequate. It does not explain what 'business contexts' are, what the batch operation does, how the parameters relate, what the response looks like, or any behavioral constraints. An agent has almost no information to correctly invoke or reason about this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of the parameters. The schema shows required fields 'context' and 'contexts' and optional fields like 'request_id' and 'idempotency_key', but the description does not clarify their meaning, formats, or relationships. The description fails to compensate for the lack of schema documentation, leaving agents without essential parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'business contexts batch upsert' is essentially a restatement of the tool name with spaces. It identifies the resource (business contexts) and the action (batch upsert), but adds no detail about what an upsert entails or what makes this distinct from sibling batch operations like edge_batch_upsert or business_mappings_batch_upsert. There is no elaboration on the specific behavior, so it provides minimal value beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the many sibling tools (e.g., business_mappings_batch_upsert, node_semantic_batch_upsert). There is no mention of prerequisites, intended use cases, or exclusions. An agent is left without any contextual advice on tool selection, making this dimension completely unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not state whether the operation is read-only, what data it returns, whether it requires authentication, or any side effects. The description is silent on all behavioral aspects, leaving the agent to guess.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, this is under-specification, not conciseness. A concise description would pack meaningful information into few words; here, 'get edges' offers no substance and could mislead an agent into assuming it is a trivial operation. There is no structure or front-loading of key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 2 required, no output schema, no annotations), a complete description would need to explain purpose, parameter usage, return format, and contextual relations to siblings. This description is entirely inadequate, offering nothing beyond a bare label. An agent has no basis to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of any of the 10 parameters (e.g., repository_id, target_commit, from_node_ids). Parameter names alone in the schema are insufficient without context; the description must compensate but fails to do so. This is a critical gap for a tool with two required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'get edges' essentially restates the tool name with no elaboration on what edges are, what operation it performs, or how it differs from similar tools like node_batch_get or edge_batch_upsert. It is a near-tautology, providing minimal clarity beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. Sibling tools include many related operations (e.g., get_nodes, edge_batch_upsert, traverse_graph), but the description does not explain the specific scenario for get_edges or any distinguishing use case. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the full burden of behavioral transparency. The description only states 'find paths', with no disclosure of side effects, return format, cost, or any other behavioral characteristics. This is critically insufficient for a tool with likely read-only graph traversal behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It provides no useful information, so it fails the 'every sentence should earn its place' test. A single vague phrase does not constitute good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (15 parameters, no output schema, no annotations), the description is wholly inadequate. Nothing about the graph context, expected inputs, outputs, or edge cases is covered. An agent using this description would have no understanding of how to correctly invoke or interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no explanatory text for any of the 15 parameters. The description does not compensate by mentioning any parameter names, types, or relationships. The agent has zero guidance on how to populate parameters like depth, direction, edge_types, or budgets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'find paths' is essentially a tautology of the tool name, providing no information about what kind of paths, in what context, or for what purpose. It does not differentiate from similar tools like search_paths or traverse_graph, and offers no detail on the resource or scope of the 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/5
Does 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 such as search_paths or traverse_graph. There is no mention of applicable scenarios, exclusions, or prerequisites, leaving the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses zero behavioral traits. It does not state whether the operation is read-only, what side effects occur, what authentication or permissions are needed, or what the response format looks like. The description carries the full burden but provides nothing beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), which makes it technically concise, but this is under-specification rather than good conciseness. There is no structure, no separation of concerns, and no information beyond the literal tool name. It fails to use the available space to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotation support, the description is woefully incomplete. An agent has no idea what the tool returns, how to filter results, or what the required parameters actually represent. This is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 9 input parameters (3 of which are required). Parameters like repository_id, target_commit, and scope_id are left completely undefined. With no parameter documentation in either the schema or the description, an agent cannot correctly populate the inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list domains' restates the tool name almost verbatim, providing no additional specificity about what 'domains' refers to in this system. It fails to distinguish the tool from sibling list operations like list_scopes or list_concepts, which are clearly related. The purpose is implied but not clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description gives no context about typical use cases, required prerequisites, or scenarios where another listing tool would be more appropriate. An agent would have to guess based on 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the operation with no mention of side effects, idempotency (despite an idempotency_key parameter), authorization needs, or data transformation behavior. This is a significant gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it is under-specified rather than efficiently concise. It fails to convey necessary information, resembling the minimal 'Process' example. It is not a balanced single sentence that earns its place; it is a bare restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects, batch upsert, no output schema) and lack of annotations, the description is utterly inadequate. It leaves the agent without essential details about input structure, behavior, or return values, making correct invocation nearly impossible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions no parameters explicitly. It adds no meaning to the context, mappings, request_id, tool_version, schema_version, or idempotency_key fields. The agent has no guidance on what the mappings array should contain or how context is structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('upsert') and resource ('business mappings'), which gives a basic sense of operation. However, it does not explain what business mappings are or distinguish this batch upsert from siblings like business_directory_batch_upsert or business_contexts_batch_upsert. It adds no meaning beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, conditions, or exclude scenarios. With many sibling batch upserts and read/search tools, the agent is left without direction on when to prefer this tool.
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:

[![code-context-storage-mcp MCP server](https://glama.ai/mcp/servers/Jrains-ux/code-context-storage-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Jrains-ux/code-context-storage-mcp)

Score Badge

Copy to your README.md:

[![code-context-storage-mcp MCP server](https://glama.ai/mcp/servers/Jrains-ux/code-context-storage-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Jrains-ux/code-context-storage-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jrains-ux/code-context-storage-mcp'

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