canton-ccpedia

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-read-only (readOnlyHint=false) and open world. Description adds that it proxies call and returns result or connect instructions, but lacks detail on potential side effects or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single paragraph with four sentences, each contributing value. It is concise and front-loaded with the main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description adequately explains return value (result or connect instructions) and constraints. Sufficient for an orchestration tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and parameters are well-described in schema. Description restates them without adding significant new semantics beyond context (e.g., server ID from list_canton_mcps).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Federate a tool call to another Canton MCP server' and distinguishes it from sibling like list_canton_mcps. Verb 'federate' and resource 'tool call' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (Canton MCPs) and limitation 'Only free, hosted, no-auth Canton MCPs can be proxied; local or paid ones return connect instructions.' References list_canton_mcps for server IDs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description discloses input flexibility (single name or prose block), that it scans prose for every deprecated item, and the three possible return values (DEPRECATED with replacement, CURRENT, NOT_FOUND). This adds substantial behavioral context beyond the read-only/idempotent hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, with each sentence adding distinct value: scope, examples, exclusions, usage directive, input flexibility, and return behavior. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description covers return values, input modes, scope, and usage, making it fully self-sufficient for a one-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the 'name' parameter, but the description adds that a longer block of text is accepted and scanned for deprecated items, enriching parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks whether a Canton/Daml toolchain item is deprecated, with specific examples (daml-assistant, Navigator, dpm). It explicitly distinguishes from a general deprecation checker, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'ALWAYS call before recommending any Canton tool or package,' and clarifies it's Canton-specific, not for npm/pip. This gives clear when-to-use guidance and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context by detailing the specific types of community signals returned (forum thread reply ratios, mailing list debate volume, highest-rated reply). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loading the main purpose and key details. Every sentence provides value: the first states what it does and what it includes, the second clarifies scope and limitations. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the essential functionality. It mentions what data is returned and that it is a structured roundup for summarization. However, the exact structure of the output is not specified, leaving some ambiguity about how the data is formatted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the parameter 'topic' already has a description in the schema. The tool description does not add further meaning, such as examples or formatting, beyond stating it is a topic to assess. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Surface' and resource 'signals of what the Canton community thinks about a topic', listing concrete elements like forum thread reply ratios and mailing list debate volume. It distinguishes itself from sibling tools by stating 'Canton-specific' and explicitly noting it is not sentiment analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by stating 'Canton-specific' and contrasting with sentiment analysis, but it does not provide explicit guidance on when to use this tool over alternatives like search_community or get_discussion. No exclusions or alternative tool names are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe, read-only behavior is clear. The description adds value by specifying it is Canton-specific and listing the types of activities aggregated (CIP status changes, mailing activity, dev-fund proposals). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with two sentences that front-load the key information: what is aggregated, the window, and the use case. Every sentence adds value without repetition or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, no output schema, and annotations cover safety, the description provides enough context about the tool's behavior and the types of data included. However, it does not hint at the output format (likely a JSON object with counts), which would improve completeness. Still, it is fairly complete for a summary aggregator.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, window_days, has a schema description with 100% coverage ('Window in days, 7-365.'). The tool description does not add additional information about the parameter beyond implying it defines the aggregation window. Thus, baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it aggregates governance throughput over a window, specifying exactly what is included: CIP status changes, mailing activity, and dev-fund proposals. It distinguishes itself from siblings like get_cip or list_governance_votes by being a summary aggregator, and explicitly states it is Canton-specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case: 'Use to summarise what governance has shipped this quarter?' This gives context for when to use it. However, it does not explicitly state when not to use it or mention alternative tools, so it loses a point for missing exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no further behavioral context beyond the mapping purpose. It does not contradict annotations, so a score of 3 is appropriate as annotations carry the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences. The first sentence defines purpose with examples, and the second provides usage guidance. Information is front-loaded with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description fully covers purpose, scope, usage boundaries, and examples. It is complete for its complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description listing examples. The tool description adds context by stating the concept is an EVM concept and providing examples like 'smart contract', 'wallet', etc. This adds some value but does not significantly surpass the schema's description. Baseline 3 is suitable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool maps an EVM concept to its Canton Network equivalent, using a specific verb 'map' and resource 'concept'. It distinguishes from sibling tools like 'get_started_guide', meeting the criteria for specificity and differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use guidance: 'Use for single concept-to-concept translations' and when-not-to-use: 'use get_started_guide for a full EVM-to-Canton learning path'. It explicitly names an alternative sibling tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds context that the tool searches two corpora and is Canton-specific, which is useful but not extensive behavioral detail beyond what structured fields provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences that each add value: purpose, sibling differentiation, scope, and usage context. It is not overly long, though the phrase 'across BOTH the canton-dev-fund proposals corpus AND ecosystem_projects' could be slightly shortened. Overall, it is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one input parameter with full schema coverage, strong annotations, and sibling context, the description covers purpose, scope, differentiation, and usage scenario. It does not describe output format, but the tool's purpose (finding similar projects) implies a list of results, which may be acceptable. It is mostly complete for an AI to understand when and how to use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description of the 'idea' parameter as 'One-paragraph project idea or capability description.' The tool's description does not add additional parameter information beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds similar projects across two specific corpora (dev-fund proposals and ecosystem projects) and explicitly contrasts with sibling find_similar_projects, which only searches the live directory. It provides a specific verb ('find'), resource ('Canton ecosystem projects + dev-fund proposals'), and scope ('Canton-specific').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says this tool is 'Broader than find_similar_projects' and clarifies when to use it ('before submitting a new proposal'). It names the alternative tool and its limitation, giving clear guidance on when to choose this tool over find_similar_projects.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent behavior. The description adds that it walks the graph, returns full chain with statuses, and is Canton-specific. This provides valuable context beyond the annotations, though it lacks details about error handling or output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences, each adding essential information: action and result, what the chain contains, accepted input formats, and usage context. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter, the description covers key aspects: purpose, input, and usage context. It could mention possible errors or the exact status values, but these are minor given the tool's simplicity and the annotations providing safety assurances.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'cip_id' is fully described in the schema (100% coverage). The description repeats the accepted formats but adds no significant new meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameter well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool walks the CIP 'requires:' graph to find a chain of prerequisites. It distinguishes from siblings by specifying 'Canton governance only' and focusing on CIP dependency chains, which is unique among sibling tools like get_cip or ecosystem_dependency_graph.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises 'Use when planning around a CIP that hasn't shipped yet.' It also specifies accepted input formats (CIPs and PR drafts). However, it does not mention when not to use it or suggest alternative tools for broader dependency analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly, idempotent, and non-destructive nature. The description adds that it returns counts and recent statements, providing additional context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy: the first states purpose and output, the second distinguishes from a sibling. Every sentence is essential and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter, no output schema, and comprehensive annotations, the description covers what the tool does, its output, and differentiation from a sibling, making it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter. The description enriches by explaining the topic is used to cross-check across docs, forum, and GitHub, adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds contradictions between docs, forum, and GitHub on a topic, with a specific verb and resource. It also distinguishes itself from the sibling tool get_kb_drift.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides when to use this tool by contrasting it with get_kb_drift, specifying that it compares multiple surfaces versus foundation_kb vs live releases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, read-only, idempotent behavior. The description adds beyond that by explaining it returns top 3 matches from forum and GitHub each. It does not cover potential rate limits or performance, but given annotation coverage, it is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with clear structure. The first sentence states the core function, the second provides usage guidelines. Every sentence adds necessary information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (error diagnosis with cross-referencing historical data), the description covers input requirements, expected output format (top 3 matches from forum and GitHub), and domain scope (Canton-specific). No output schema exists, but the description adequately explains return value structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so schema already documents parameters. The description adds value by explaining that longer/distinctive text yields better matches and gives examples of valid error codes (e.g., TOPOLOGY_TOO_MANY_PENDING_TOPOLOGY_TRANSACTIONS). It also clarifies the default limit of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: diagnosing Canton/Daml/Splice error messages, stack traces, or error codes by searching CCPEDIA history. It specifies the verb 'diagnose' and the resource (error messages), and distinguishes it from sibling tools like semantic_search by explicitly stating what kind of input is required.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool (literal error strings or codes) and when not to (symptom descriptions without error text), directly naming the alternative tool (semantic_search). It also restricts usage to Canton-specific issues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds context that this is a quick dependency picture, which is consistent and slightly beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and every word adds value. No wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter, full annotation coverage, and no output schema, the description provides sufficient context: purpose, use case, and scope (Canton-specific). It is complete for agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'topic' is fully described in the schema (100% coverage). The description mentions 'matching a topic' but adds no additional semantic detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool maps ecosystem projects matching a topic to SDK versions and repos, with a specific verb and resource. It distinguishes itself from sibling tools by focusing on dependency graph generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete use case ('if I build with X SDK version, who else is on it?') but does not explicitly state when not to use it or list alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral details: the fallback search logic (matching first by name+category then description) and Canton-specific scope, which go beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences covering purpose, search fields, fallback, and scope. No filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema), the description adequately explains behavior. It could mention result format or pagination, but with schema covering limit and schema coverage 100%, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters (pattern and limit). The description does not add further parameter semantics beyond what the schema provides, resulting in a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a pattern search across the Featured Apps catalogue using free-text, specifying the fields searched (name, category, description) and the fallback logic. It also notes Canton-specificity, distinguishing it from generic search tools like 'search' and 'semantic_search'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for pattern-based queries on the Featured Apps catalogue, but does not explicitly state when to use this tool versus alternatives such as 'list_featured_apps' or 'semantic_search'. No guidance on when not to use is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly, idempotent, and non-destructive. The description adds that it searches titles and bodies, and returns matching CIPs, providing behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The first sentence defines the core functionality, the second explains usage. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is complete: it specifies input type, domain, expected output ('matching CIP(s)'), and typical use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter with full schema description coverage (100%). The description does not add meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('find'), resource ('CIP(s)'), and domain ('Canton-specific'). It clearly differentiates from sibling search tools by focusing on matching a feature description to CIPs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use it: 'Use to answer "is there a CIP for X?"'. It does not state when not to use or provide alternatives, but the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds value by disclosing the exact filtering mechanism (rendered HTML with <pre> or <code> blocks) and the topic matching, which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the main purpose, and follows with a concise technical filter. Every sentence earns its place; no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, strong annotations, and complete schema (including offset behavior description), the description provides sufficient context for a read-only filtered-list tool. It explains exactly what is filtered and the scope (forum posts), which is adequate even without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage of all three parameters (topic, limit, offset) with descriptions, so the baseline is 3. The tool description does not add additional meaning or usage details for these parameters, only referring to 'topic keyword' indirectly, which is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Find') and resource ('Canton/Daml code snippets in forum posts on a topic'). It further explains the filtering logic (rendered HTML contains <pre> or <code> blocks AND matches topic), which distinguishes it from generic search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear context is provided: this tool searches forum posts for code snippets on a specific topic, and the 'Canton-specific' qualifier narrows its scope. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by explaining the heuristic method ('overlap of tags + adjacent categories'), which helps the agent understand behavioral traits beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and each sentence adds necessary information without redundancy. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (single parameter, no nested objects, good annotations), the description is largely complete. It covers purpose, method, and scope. However, it could mention the format of the output (list of projects) or how results are ranked, but this is not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a minimal description for the 'project' parameter. The tool description adds context ('Given one Canton ecosystem project') but does not significantly enhance understanding of the parameter semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds complementary projects based on tags and categories, using a specific verb ('find') and resource ('collaboration opportunities'). It distinguishes from siblings like 'find_similar_projects' and 'list_ecosystem_projects' by focusing on complementarity rather than similarity or enumeration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('Canton-specific project', 'lightweight heuristic') but does not explicitly state when to use this tool vs alternatives like 'find_similar_projects' or 'search'. No exclusions or when-not-to-use guidance provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe read operation. The description adds context about data sources (forum activity, GitHub volume) but no additional 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with immediate value, no redundancy, and clear front-loading of the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description could explain the return format (e.g., ranked list with scores). It is adequate given the tool's simplicity but leaves some gap for expected output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for both parameters (topic, limit). The description does not add extra meaning beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool ranks likely Canton experts on a topic using forum activity and GitHub volume. It specifies the scope (Canton-specific) and the data sources, making it distinct from siblings like search_community or list_community.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives, such as search_community or get_discussion. It does not mention when not to use it or provide context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true and destructiveHint=false. The description adds behavioral traits: returns nothing when no match, does not return fixes/solutions, and is Canton-specific. This context is valuable beyond annotations and contains no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first fronts the core purpose with bullet-like details, the second adds exclusions and alternatives. Every word is necessary and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and simple parameters, the description covers purpose, usage boundaries, alternatives, and parameter hints. It is fully complete for an AI agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters. The description adds extra guidance: for 'description' it specifies 'Short prose, not a stack trace' and directs to diagnose_error for stack traces; for 'limit' it clarifies 'Max rows per source'. This goes beyond basic schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it surfaces known unresolved problems (forum threads with zero replies but high views, open GitHub issues) matching a free-text description, answering 'is anyone else hitting this?'. It is Canton-specific and distinguishes from sibling tools like semantic_search, get_doc, and get_issue_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (to check for known open issues) and when not to use (does not return fixes, solutions, config, or how-to steps). Provides an alternative: for 'how do I fix / configure / why does X happen' use semantic_search then get_doc. This is excellent guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about filtering by top-volume contributors, but does not detail ordering, pagination, or what defines 'top-volume.' This adds moderate value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with front-loaded purpose. Every sentence earns its place, and there is no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with one parameter and no output schema, the description is adequate. It explains the filtering and domain specificity, though details on result format or 'top-volume' definition are missing. Still, it is sufficiently complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description and examples. The tool description reinforces the parameter's purpose ('on a topic') but does not add significant new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Surface' and clearly identifies the resource as 'forum/mailing posts authored by top-volume Canton contributors (likely maintainers) on a topic.' It also specifies 'Canton-specific,' distinguishing it from sibling tools like search_mailing_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'Use when you want to weight expert voices over the general forum.' This provides clear guidance on context, though it does not explicitly mention alternatives or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: it reveals the heuristic (keyword matching on release bodies) and scope (Canton-specific), which are beyond what annotations provide. This gives the agent a clear understanding of 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise—two sentences—with no wasted words. The first sentence states the primary purpose, and the second provides the heuristic and scope, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, no output schema, no nested objects), the description covers the essential context: purpose, heuristic, and scope. It lacks detail on the response format, but this is acceptable for a lightweight tool. Minor improvement would be to note that results are filtered release notes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter 'limit', with a full description in the schema. The tool description does not add any additional meaning or usage guidance for the parameter, landing at the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to surface release notes containing security or CVE fixes. It specifies the scope (Canton-specific) and the heuristic mechanism (keyword matching), effectively distinguishing it from siblings like search_release_notes or get_latest_release.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for finding security patches but does not explicitly state when to use this tool versus alternatives such as search_release_notes. No exclusions or alternative tool mentions are provided, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond these by specifying the search scope ('searches only the live ecosystem directory') and the matching mechanism ('matching across title + category + description + tags'). It doesn't over-explain but provides useful constraints. A slight gap exists regarding result ranking, but overall it adds meaningful transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core action ('Find...'). Every sentence earns its place: the first defines what it does, the second notes the scope ('Canton-specific'), and the third gives usage guidance and an alternative. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 well-documented parameters, read-only annotations, no output schema), the description is sufficiently complete. It covers the search target, fields matched, live-directory limitation, and provides situational guidance (checking overlap before proposing a project). The absence of return-format details is acceptable since there is no output schema to elaborate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The tool description adds a modest layer by explaining that the 'description' parameter is a free-text query matched against multiple fields, but this largely recapitulates what the schema already implies. Limit and offset are fully documented in the schema, so the description doesn't add substantial parameter semantics beyond the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Find Canton ecosystem projects most similar to a free-text description' and specifies the matching fields (title, category, description, tags). It further distinguishes itself from siblings by noting it 'searches only the live ecosystem directory' and is 'Canton-specific', differentiating it from detect_builder_overlap and other search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: 'Useful before proposing a project to check overlap.' It also names an alternative for different needs: 'to also check pending/past Dev Fund proposals for the same idea, use detect_builder_overlap instead.' This clearly guides the agent on when to use this tool versus a sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it queries multiple sources but does not detail response format or potential rate limits. It is consistent with annotations but adds limited behavioral context beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that front-loads the core purpose and then provides usage guidance. It is efficient but could be slightly tighter. Every sentence is informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low parameter count, 100% schema coverage, and no output schema, the description covers the essential aspects: scope, use cases, and exclusions. It does not describe the response format, but for a search tool this is often implicit. It feels complete enough for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description reinforces the topic parameter and implies the limit_per_source parameter. It does not add significant additional meaning beyond what the schema provides, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a free-text query across CCPEDIA's entire corpus, listing all sources. It distinguishes from siblings like get_cip_citations and specialized single-source tools, specifying that this is for cross-source roundups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (exhaustive cross-source roundup on a topic) and when not (if user has a specific CIP ID, use get_cip_citations; for narrow single-source searches, use specialized tools). Provides clear alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds no behavioral traits beyond confirming the tool is read-only and Canton-specific. With annotations present, the description's marginal value for transparency is limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, immediately stating the purpose. It consists of three sentences with no redundancy, efficiently covering purpose, scope, and usage guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is largely complete. It defines the tool's purpose, scope, and usage boundaries. The lack of return value description is a minor gap, but not critical given the tool's straightforward nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single enum parameter. The description adds value by spelling out the full names of each API (e.g., 'JSON Ledger API' instead of just the enum value 'json_ledger_api'), helping the agent understand the parameter more intuitively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a structured reference for a specific Canton Network API, listing the exact APIs. It distinguishes itself from sibling tools like search/semantic_search by explicitly noting they are for broader doc lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool (when a user names one of the listed Canton APIs) and when not to use it (for GitHub, REST, or non-Canton APIs). It also directs users to search/semantic_search for broader lookups.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it as read-only and idempotent. The description adds valuable behavioral context: it enumerates the returned fields, notes that some metrics (TVL, volume, users) can be null depending on the data source, and specifies that it is Canton-specific. This goes beyond simple safety annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action and target, and every sentence adds value. It efficiently covers what the tool does, what it returns, and a key caveat without any redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read tool with no output schema, the description is remarkably complete. It lists all return fields, explains the null behavior, and notes the Canton-specific scope. An agent has enough information to understand what it will receive and when values may be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents the single app_id parameter, including its type and the ability to use a prefix. The description's mention of 'contract id from the Scan API' adds only marginal clarification and largely duplicates the schema description. With 100% schema coverage, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches metrics for one specific Featured App by app_id, distinguishing it from list-style siblings like list_featured_apps. The verb 'Fetch' and specific resource 'metrics for one specific Featured App' leave no ambiguity about its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when you have an app_id and need detailed metrics for a single app, and the parameter description references list_featured_apps for obtaining the id. While it doesn't explicitly list alternatives or exclusion criteria, the context is clear enough for an agent to select it over similar tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context about data sources (release notes, forum/GitHub reports) and the Canton-specific scope, enhancing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences) and front-loaded: first sentence states purpose, second gives usage guidance, third provides parameter instructions. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage, and parameter semantics. It lacks explicit detail about the output format, but given the clear annotations and the comparative nature of the tool, the information is sufficient for most agents.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning by specifying that version strings should be passed 'as they appear in github_releases tags (with or without the leading "v")' and explains that the optional 'repo' parameter is auto-inferred, aiding correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('compare'), the resource ('Canton/Daml/Splice SDK versions'), and the scope ('Canton-specific'). It distinguishes from similar tools like 'get_sdk_changelog' by specifying the comparative nature and additional data sources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use when a developer is planning an upgrade and asks "what breaks moving from X to Y?"', providing clear context. While it does not name specific alternatives among siblings, the usage scenario is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns only what the proposal says, not its on-chain fate, and that it works only within a specific ecosystem. This adds behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with two purposeful sentences and a short ecosystem note. It front-loads the action and examples, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature of the tool (one parameter, no output schema, read-only), the description is comprehensive. It covers what the tool returns, how to use it, and how it differs from related tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description. The tool description reinforces the ID format and provides additional examples (including bare number '0042'), adding minor extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it fetches the full markdown body of a single CIP by its ID, with specific examples. It distinguishes itself from sibling tools like get_cip_vote_outcome, get_cip_history, and list_cips, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool (to read what the proposal says) and when not to (for on-chain fate, use get_cip_vote_outcome; for timeline, get_cip_history; for browsing, list_cips). It also notes the ecosystem scope (Canton/Daml/Splice only).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds valuable behavioral context about PDF extraction and the distinction between full text vs index entry. It does not contradict annotations, though it omits potential edge cases like empty attachment lists or error behavior, so a slight deduction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, then adds necessary clarifications about historical context, related tools, and scope. Every sentence earns its place without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter signature and no output schema, the description fully covers what the tool returns (filenames, page counts, URLs, extracted text), addresses the older-CIP ambiguity, and disambiguates from siblings, making it complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'id' is fully documented in the schema with examples ('0001', 'CIP-0042'), providing 100% coverage. The description does not need to add parameter syntax, and it doesn't, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action ('Get'), the resource (file/PDF attachments of a single CIP), and the contents (filename, page count, URL, extracted text). It distinguishes from sibling tools like get_cip and get_cip_votes, and clarifies the Canton-only scope, ensuring no ambiguity about what it does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool vs alternatives: 'For the parsed who-voted-how breakdown use get_cip_votes.' It also explains the historical nuance (older CIPs publish proposal as PDF) and warns against non-Canton 'CIP' schemes, giving clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the description aligns with. It adds context about CCPEDIA-unique per-message granularity and that it returns per-source counts and samples, but does not mention any potential rate limits or performance aspects. Still, the added value is significant beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and informative, but slightly lengthy. Every sentence adds value, starting with a clear purpose, listing included sources, then distinguishing from siblings. Could be slightly trimmed, but still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the lack of an output schema, the description explains that it returns per-source counts AND samples for each listed source. It gives a high-level overview sufficient for an agent to understand the tool's output, though more detail on the output structure would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has only one parameter (cip_id) with a clear description including examples. Schema coverage is 100%, so the description does not need to add much. It does not provide additional parameter-specific details beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns a comprehensive citation graph for a CIP, listing all the specific sources (sibling CIPs, forum posts, mailing-list messages, etc.) and distinguishes itself from siblings like get_cip, get_cip_votes, get_cip_mentions, and full_context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('who is referencing CIP-X and where' / impact analysis, known CIP id) and when not to use, providing alternatives: get_cip for proposal text, get_cip_votes for votes, get_cip_mentions for legacy aggregated counts, and full_context for unknown CIP id.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds context that only history is returned, no proposal body or votes. No behavioral contradictions or omissions beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: first defines purpose and output format, second provides use case, third clarifies domain scope. No fluff, front-loaded with the most critical information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description fully explains what is returned, what is excluded, and when to use it. The annotations cover safety and idempotency. No further information needed for correct tool selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for the single parameter 'id'. Description does not add extra parameter-level details beyond the schema, but the baseline is 3 due to high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool retrieves status-transition timeline of a single CIP, specifying the exact output (dated from->to changes). Explicitly differentiates from sibling tools get_cip and get_cip_votes by naming them and stating what is excluded.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use case: 'how/when did CIP-X move through governance' questions. Also gives clear when-not-to-use by stating it does not return proposal body or vote tallies, and restricts scope to Canton ecosystem, excluding other 'CIP' schemes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context beyond annotations by specifying what the report contains (PRs, ecosystem projects, status transitions) and 'Canton governance' as a domain qualifier, which helps set expectations for the output without requiring return format details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, then usage. The fragment 'Canton governance.' is terse and slightly disconnected, but the overall message is efficient without wasted words, earning a 4 rather than 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a single parameter, no output schema, and strong annotations, the description covers the essential aspects: what it does, what it tracks, and when to use it. It lacks details on output structure, but this is not mandatory since no output schema exists, and the complexity is modest.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage for the single parameter cip_number, with clear examples. The description reinforces that it is 'one CIP' but adds no additional semantic detail beyond the schema, matching the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reports implementation status for a single CIP, listing specific components (linked dev-fund PRs, related ecosystem projects, status transitions). It distinguishes from siblings like get_cip or get_proposal_milestones by focusing on code/grants tracking against the proposal, using a specific verb 'report' and resource 'CIP implementation status'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use after find_cip_for_feature to gauge readiness', providing a direct usage context and sequencing with an alternative tool. It also scopes to 'one CIP', implying not for bulk comparisons, but lacks explicit 'when not to use' scenarios, so not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral details: returns aggregated per-source counts, not individual items. No contradictions. Could add more on rate limits or pagination, but overall good.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the main purpose, and each sentence adds distinct value (purpose, use case, exclusions, ecosystem note). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter, good annotations, and no output schema, the description is complete. It explains the return type (aggregated counts), what sources are covered, and when to use alternatives. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter 'id' with schema description covering 100% of its meaning. The tool description adds no extra semantics beyond the schema, which already explains the CIP ID format. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Find' and resource 'CIP mentions', lists specific sources (forum threads, mailing-list posts, etc.), and distinguishes from siblings like get_cip_citations, get_cip, and get_cip_votes. It also clarifies the ecosystem scope (Canton only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use ('reverse-reference lookup' for 'who is discussing CIP-X'), when not to use (use get_cip_citations for individual items), and what tools to use instead for proposal text or votes. Also clarifies ecosystem limitation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark read-only/idempotent/non-destructive, and the description adds meaningful behavioral specifics: it reads the on-chain ledger, returns vote requests with outcomes and dates, and clarifies the matching mechanism ('whose text cites this CIP'). The concrete example (CIP-0116) further illustrates real-world output. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, each carrying distinct weight: purpose, return type, contrast with sibling, and scope/example. It is front-loaded with the core question and contains no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with full annotations and schema coverage, this description is complete: it explains what counts as a result (vote requests citing the CIP), what the output contains (outcomes and dates), how it differs from related tools, and ecosystem boundaries. No output schema is present, but the return concept is clearly described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters have descriptions), so baseline is 3. The description adds value by clarifying that `cip_id` is matched against citations in vote request texts, and that `limit` returns newest-first (though schema also states this). This citation-matching context goes beyond the schema's basic type/format info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Find out') and resource ('Canton Improvement Proposal... acted on ON CHAIN'), then details the return set ('every DSO governance vote request whose text cites this CIP, with outcomes and dates'). It explicitly contrasts with sibling `get_cip_votes` (mailing list vs ledger), making the tool's unique scope unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly directs when to use this tool: 'This answers was it decided, which the mailing-list tools cannot' and names the alternative (`get_cip_votes`) that reads discussion on the mailing list. It also disambiguates ecosystem scope: 'Canton ecosystem only, not Cardano or other CIP schemes.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so base expectations are clear. The description adds the data source (cip-vote mailing list), which provides helpful context beyond annotations. No mention of pagination or data freshness, but acceptable given simplicity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: two main sentences plus a scope note. Every sentence adds unique value. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple structure (one required param, no output schema) and rich annotations, the description provides sufficient context for an agent to understand and invoke the tool correctly. It covers purpose, usage, exclusions, and limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description. The description adds minimal extra meaning (source context) but does not elaborate on the parameter beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's purpose: retrieving formal vote tallies for Canton Improvement Proposals. It uses a specific verb ('Get'), names the resource ('formal vote tally'), and distinguishes from sibling tools like get_cip_attachments and get_cip_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use cases ('who voted how' / approval-trail verification) and provides exclusions ('not the attachment PDFs... or status timeline'). It also limits scope to Canton ecosystem, avoiding confusion with Cardano CIPs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context about data derivation (live joins from github_releases and mailing_messages) and freshness (fresher than KB snapshot). This exceeds what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat long but front-loads the main purpose and includes necessary context. Every sentence adds value, though it could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers what the tool returns (versions, deployment status, upgrade windows) and how it works. Additional details about output format would improve completeness but are not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter semantics since there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the latest versions of Canton SDK, Splice, Daml, and DPM packages across multiple packages, plus deployment status and upgrade windows. It distinguishes itself from sibling tool 'get_latest_release' by noting that tool is for a single package's release notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases such as when a user asks 'what version should I target?' or 'what is on MainNet?', and gives a specific alternative for single-package release notes. This guides the agent on when to use this tool versus others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only and idempotent (safe, no side effects). The description adds valuable context: it is 'Canton-only', 'served from CCPEDIA's cached forum index' (explaining source and caching), and specifies the return includes 'the first ~15 posts' (indicating a limit). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at 4 sentences, front-loaded with the main action and what is returned. Every sentence adds distinct value (caching, source, sibling guidance, id origin). Slightly longer than minimal but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (one param, no output schema), the description covers purpose, parameters, return content, caching, and usage context. It lacks details on error handling (e.g., not found) but is otherwise comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with description for the 'id' field. The description adds extra meaning by calling it a 'numeric topic id' and noting how to get it ('from search results or trending'). This goes beyond the schema's 'Forum topic ID'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'Get', the resource 'a single thread from the official Canton Network community forum', and specifics about what is returned (title, category, view/post counts, first ~15 posts). It distinguishes from sibling tools by naming get_github_discussion and get_mailing_thread.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates when to use this tool ('for the WEB FORUM') and when to use alternatives ('For GitHub Discussions use get_github_discussion, for sync.global mailing-list threads use get_mailing_thread'). It also advises how to obtain the id ('from search results or trending').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context about fetching 'FULL text' and content types (commands, flags, sections). No contradictions. The description provides sufficient behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a brief usage note, all front-loaded with the core action. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple fetch tool with no output schema, the description adequately explains purpose, usage context, and parameter origin. However, it does not describe the return format or potential errors, but given the tool's simplicity and annotations, this is not a critical gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage: the single 'id' parameter is clearly described as 'Doc page ID (from search/semantic_search results)'. The description reinforces that the id comes from search/semantic_search, adding useful context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Fetch the FULL text of one indexed Canton-ecosystem documentation page'), identifies the specific resource (Canton/Daml/Splice docs), and distinguishes it from sibling tools by specifying it is for use after search/semantic_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this AFTER search or semantic_search returns a doc id' and warns 'Not a discovery tool; use search/semantic_search first.' This provides clear when-to-use and when-not-to-use guidance, including naming alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe read. The description adds behavioral context beyond annotations by specifying the exact sources of gaps (forum, mailing list, proposals) and the 'Canton-specific' constraint. It doesn't describe return format, but the presence of strong annotations lowers the bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, then provides concrete examples, a usage intent, and an alternative. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one optional parameter, no output schema), the description is complete: it states the three gap categories, the geographic scope (Canton-specific), and the intended use case. No critical information is missing for an agent to decide on invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the 'limit' parameter fully documented ('Max rows per gap type (default 5)'). The description adds no additional parameter information, but since the schema carries the full burden, baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('surface') and resource ('ecosystem gaps'), listing three concrete gap types: unanswered forum threads, unreplied mailing threads, and unlabeled Dev Fund proposals. This distinguishes it from siblings like get_funding_landscape and get_trending.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use to find where the ecosystem needs help' and names an alternative: 'For per-category funding levels use get_funding_landscape.' This gives clear when-to-use and an alternative, fully satisfying the criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnly and idempotent. Description adds that it returns 3 nearest entries which may not exactly match, disclosing approximate matching behavior beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is reasonably concise and front-loaded with purpose, but slightly verbose with extensive usage guidance. Still well-structured and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single parameter and no output schema, the description fully covers purpose, scope, limitations, and alternatives. No critical information is missing for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description. The description only adds examples of questions, providing minor extra value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it looks up answers in Canton Network developer FAQ, specifying the domain and that it returns 3 nearest entries. It distinguishes from siblings like semantic_search, get_started_guide, and get_api_reference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when not to use (other blockchains, general questions) and advises alternatives (semantic_search, get_started_guide, get_api_reference) when results are insufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: it returns 'matched-page snippets' rather than full documents, and it clarifies scope ('Canton-only', 'not the curated knowledge base'). This enriches the agent's expectations without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the main action and scope, then usage guidance. Every sentence adds distinct value: what it retrieves, how it searches, and when to use it. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with two well-documented parameters and no output schema, the description covers purpose, source, scope, return format, and usage context. It is fully self-contained and matches the complexity of the tool. For example, it clarifies what kind of snippets to expect and limits applicability to Canton-specific queries.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters (topic, limit) are fully described in the schema with example values and constraints, so schema coverage is 100%. The description adds 'Free-text topic search' but does not elaborate beyond the schema, meaning its contribution is neutral. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Retrieve') and resource ('official Canton Foundation pages (canton.foundation)'), listing concrete content types (team and board bios, working groups, membership process, grants program). It also differentiates from sibling tools by noting it searches CCPEDIA's index rather than the curated knowledge base and is Canton-only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'Use when a user asks about Foundation people, governance structure, or member/grant processes.' It also provides a light exclusion ('not the curated knowledge base'), but does not name alternative tools or when-not-to-use scenarios, so it stops short of full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. Description adds value by detailing the content (counts by state/label, top categories, recent activity) and the Canton-scope, which goes beyond the basic safety hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first defines the tool's output, second provides usage guidance. Every word earns its place; no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one optional parameter and no output schema, the description fully explains what the tool returns and when to use it. No gaps given the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single optional parameter. The description adds example values (e.g., 'daml-tooling'), enhancing understanding beyond the schema's description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides an 'Overview of the Canton Dev Fund' with specific outputs (counts, top categories, recent activity). It distinguishes itself from sibling tools like get_ecosystem_gaps or get_proposals by focusing on funding landscape and Canton-specific context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use to gauge whether a category is over- or under-funded before proposing.' It also notes Canton-specificity. Lacks explicit when-not or alternatives, but usage is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds important behavioral context by stating it reads from a cache (not live data) and is CANTON-ONLY, which goes beyond the basic annotations. It does not describe error behavior or potential staleness, but the cache disclosure is valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each contributing critical information: the primary purpose, the cache/scope constraint, and the distinction from similar tools. It is front-loaded with the main action and avoids any filler, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-item fetch tool with no output schema, the description covers the key aspects: what it returns (full body and comments), how to identify the item (GraphQL node ID), and important constraints (cached, CANTON-ONLY). It does not detail response structure or error handling, but given the tool's simplicity and the annotations, the description is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides a clear description for the 'id' parameter with an example. The description builds on this by indicating the ID comes from list_github_discussions, adding provenance that helps the agent understand how to obtain a valid value. With 100% schema coverage, the extra context earns a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the full body and comments of a single GitHub Discussion by its GraphQL node ID. It specifies the repo scope (Canton Network or Digital Asset) and differentiates from sibling tools like get_discussion and get_mailing_thread, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: it reads from CCPEDIA's cache, not the live GitHub API, and is restricted to Canton Network or Digital Asset repos. It also notes the ID must come from list_github_discussions and distinguishes from the web forum and mailing lists, effectively guiding when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint=true, so the description adds detail on return contents (individual votes, reasons, outcome) but no additional behavioral traits like auth needs or rate limits. Adequate but not enhanced beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first details output, second provides usage context. No wasted words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (single parameter, no output schema), the description fully covers what the tool returns and when to use it. No missing elements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description already specifies it's from list_governance_votes. The description reinforces that context but adds no new semantics beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Get' and resource 'Canton on-chain DSO governance vote request', listing all details returned. It distinguishes from sibling tools like list_governance_votes (list vs detail) and compare_governance_outcomes (comparison).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use after list_governance_votes when a specific decision matters', guiding when to invoke. No explicit when-not-to-use or alternatives, but clear enough for typical use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description implies read-only operation ('look up') and repo restrictions. Annotations confirm readOnlyHint, idempotentHint, and destructiveHint, with no contradictions. Adds repo scope beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with purpose, no extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple lookup tool with no output schema; description adequately covers purpose, parameters, and scope. Return values are implied as standard GitHub issue/PR data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with descriptions; description adds clarity on repo shorthand format (e.g., 'canton-dev-fund'). Number parameter is straightforward; no additional detail needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'look up', resource 'GitHub issue or PR', and key constraints (by repo+number, limited to Canton/Daml/Splice repos). Distinguishes from sibling tools like search_github_issues.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly restricts to specific repos ('Canton/Daml/Splice repos only'), which guides appropriate usage. No explicit alternatives mentioned, but scope is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral detail: it can optionally re-run the validator via the 'refresh' parameter, and returns drift age and severity. No contradictions with annotations. This fully informs the agent of behavioral traits beyond the structured info.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise and front-loaded with the core purpose ('Report where... diverges...'). It uses three sentences followed by a usage note and a unique positioning statement. Every sentence adds value, though it could be slightly shorter without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (cross-source drift detection) and lack of output schema, the description adequately details return fields (category, key, KB value, live value, age, severity). Annotations cover safety and idempotency. The description is complete enough for an agent to decide when to use and what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only one parameter and 100% schema description coverage, the schema already explains the 'refresh' parameter. The description does not add new meaning to the parameter beyond what the schema provides (default false, stored findings). Baseline 3 is appropriate as the description adds no extra parameter insight.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Report where the Foundation Build-on-Canton KB snapshot diverges from CCPEDIA's live signals' with specific verb 'report' and resource 'KB drift'. It distinguishes from siblings like detect_drift by noting 'no other Canton MCP server exposes this kind of cross-source quality audit', making the tool's unique value clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this when a user or another agent quotes a Canton SDK / Splice / DPM / Daml version from foundation_kb and you need to confirm whether it is still current.' This provides clear context for when to invoke. However, it does not mention when not to use or mention alternatives, slightly reducing the score from 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it is Canton-specific, requires a package name, and returns specific fields (version tag, publish date, GitHub link). No contradictions. Could mention if package name is case-sensitive, but not critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first defines the tool's output and scope, second provides usage differentiation. No unnecessary words, high information density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single parameter with complete schema description, and annotations covering read-only/idempotent safety, the description fully covers the tool's purpose, parameters, and usage. No output schema needed for this straightforward retrieval.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter with schema description. The description reinforces the required package name and lists the four valid values (canton, daml, dpm, splice), adding clarity beyond the schema which also suggests full owner/repo.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets the single latest release (version tag, publish date, GitHub release-notes link) for one named Canton-ecosystem package, listing valid packages: canton, daml, dpm, splice. It distinguishes from the sibling tool get_current_versions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: when the user names a specific package, with examples. Also specifies when to use the alternative get_current_versions instead, providing clear usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral context beyond annotations: it returns every message in oldest-first order, is Canton-only, and specifies the input as a thread id from list_mailing_threads. It does not describe message structure or pagination, but for a simple read-only tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences with no filler. It front-loads the core purpose in the first sentence, then adds scope, input source, and sibling differentiation in subsequent sentences. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one required parameter, simple read operation) and lack of output schema, the description is complete. It explains the return ordering (oldest first), the domain restriction (Canton-only), the input requirement, and how it differs from related tools. No significant information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already thoroughly documents the id parameter, including both accepted forms. The description's 'Pass the thread id from list_mailing_threads' is essentially redundant with the schema's 'Thread id exactly as list_mailing_threads prints it', adding no significant new meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get every message' and the specific resource: a Canton Network governance mailing-list thread on lists.sync.global. It also distinguishes this tool from siblings by explicitly noting it is the email/mailing-list channel and not the web forum (get_discussion) or GitHub Discussions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage guidance: it is Canton-only, requires a thread id from list_mailing_threads, and explicitly contrasts with alternative channels (web forum and GitHub Discussions). This tells the agent exactly when to use this tool and when to consider alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by noting the data is cached (captured_at), sourced from the public Scan API, and is a snapshot. No contradictions. Additional context about caching and live telemetry enhances transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise: two sentences plus a short exclusion list. It front-loads the core purpose, lists return items, and then clearly contrasts with sibling tools. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description provides a thorough list of returned fields (SV list, count, voting thresholds, etc.) and mentions caching and source. It is sufficient for an agent to understand what the tool returns. Minor gap: no mention of response format or error handling, but acceptable given tool simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters, so baseline is 4 as per scoring guidelines. No parameter documentation needed. Description does not attempt to explain parameters, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the latest Canton Network on-chain state snapshot from the public Scan API. It lists specific data returned (super validators, voting threshold, etc.) and explicitly distinguishes from siblings get_network_stats and get_token_market. The verb 'Get' with precise resource 'network state' makes purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies this is Canton-only live network telemetry and explicitly names two sibling tools that should not be used for this purpose. It implies use when needing on-chain state but could be slightly more explicit about when to choose this over other tools. Overall guidance is clear and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context that the tool queries a specific data source (CCPEDIA content catalog) and not live on-chain data, which is beyond the annotations but not contradicted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste. The first sentence front-loads the purpose and contents; the second clarifies scope and provides alternatives. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description enumerates the metrics returned (CIPs, forum topics, etc.) and clarifies the data boundary. This is sufficient for an agent to understand what the tool provides and how it differs from related tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the description need not add parameter meaning. The baseline of 4 is appropriate, and the description does not waste space on nonexistent parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a clear verb ('Get') and resource ('CCPEDIA's CONTENT-CATALOG metrics'), listing exact metrics (CIPs, forum topics, etc.) and explicitly distinguishes from siblings like get_network_state and get_token_market.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use ('CCPEDIA coverage/inventory') and when not to use ('NOT live Canton on-chain stats'), and provides direct alternatives ('use get_network_state, use get_token_market').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to restate safety. It adds the detail 'indexed ... registry=npm' and 'Canton-specific', which provide some context, but does not disclose additional behavioral traits like response structure or pagination beyond what schema already conveys. No contradictions found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence: 'List the indexed Canton/Daml npm packages...'. Every word earns its place, providing the verb, resource, optional filter, and domain context without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with three optional parameters fully documented in the schema, the description covers the essential purpose and context. It lacks an explicit alternative or return format, but the schema explains the offset response detail, and annotations cover safety. The description is complete enough for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit, query, and offset with clear descriptions. The tool description adds minimal value beyond saying 'filtered by name', which maps to the query parameter. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'List the indexed Canton/Daml npm packages' with a specific scope ('optionally filtered by name') and domain ('Canton-specific'). This distinguishes it from siblings that list other resources or focus on different registries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context and an implicit exclusion with 'Canton-specific', indicating this tool is for Canton/Daml npm packages only. However, it does not name alternative tools for non-Canton packages or explicitly state when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, covering safety. The description adds that the tool searches for issues referencing the PR number, which is useful but does not disclose additional behaviors like pagination or empty results handling. With annotations present, a score of 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and concise. Every word serves a purpose, though it could be slightly more structured with separate sentences for context and action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately covers the core functionality and scope. It does not explain return value structure or edge cases, but given the low complexity, it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description already clearly defines the PR number and its repository. The tool description adds no new meaning beyond restating the context, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: listing milestone tracking issues related to a specific PR number in the Canton Dev Fund. It uses specific verbs and resources, and the mention of 'Canton-specific' distinguishes it from generic issue-listing tools among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('For one Canton Dev Fund proposal PR') but provides no explicit guidance on when to use this tool versus alternatives like search_github_issues or get_proposals. No exclusions or when-not-to-use advice is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is covered. The description adds valuable behavioral context beyond that: proposals are tracked on GitHub, returns specific fields (number, title, state, author, board status), and is restricted to the Canton ecosystem. There is no contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: definition, use case, disambiguation, return fields, and scope in three sentences. Every clause earns its place, with the most important information front-loaded and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with full schema coverage, the description is complete: it explains what the tool lists, what it returns, its scope, and how it differs from similar governance tools. Since there is no output schema, the explicit mention of return fields compensates adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for all three parameters (limit, state, offset), including defaults, constraints, and even notes about response counts. The description only restates the state filter and adds no new parameter-level information beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('List Canton Network Dev Fund grant proposals') and clearly defines scope ('community funding requests tracked on GitHub'). It also explicitly differentiates from sibling tools by stating 'NOT the same as Canton Improvement Proposals (CIPs)' and naming alternatives, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Use for "what grants/funding requests exist" questions.' It also gives clear exclusions and alternatives ('those are governance specs (use list_cips / get_cip)') and notes filterability by state, ensuring the agent knows when and how to apply this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-established. The description adds meaningful behavioral context by describing what each alert contains (deadline, affected components, source link), the severity levels, and that it is a curated feed. It doesn't go into pagination or output formatting, but this is not necessary given the simple read-only nature and full schema docs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, and every sentence earns its place. It defines the resource, includes example alert types and output fields, states filtering capability, and explicitly maps to user intents. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple read-only list tool with no output schema, but the description covers the return contents (deadline, affected components, source link), filtering, and use cases. The schema fully documents all three parameters. Given the low complexity and rich schema annotations, the description is complete enough for an agent to select and invoke the tool correctly without ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage with detailed descriptions for each parameter: level explains the severity floor and enum values, limit describes default and max, offset describes paging behavior. The description only reiterates the level filter (critical/important/ecosystem/all) and adds the 'Canton-only' context, which is not a parameter-level semantic. Given the schema's strong documentation, the description adds marginal value beyond structured data, aligning with the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as getting the 'Canton Network Radar' with a specific verb ('Get') and a specific resource. It enumerates the content (time-sensitive ecosystem alerts: breaking changes, upgrade deadlines, protocol migrations, validator actions) and even lists included fields (deadline, affected components, source link). This distinguishes it from broadly similar siblings like get_breaking_changes or get_upcoming_deadlines by framing it as a curated, all-in-one feed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'Use when a user asks what's changing, what's about to break, or what deadlines are approaching on Canton.' It also clarifies scope ('Canton-only') and the filter level options. While it doesn't explicitly name alternatives, the intent mapping is so direct that an agent can confidently select it for those question types.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the feed is merged into one time-ordered stream, defaults to the last 7 days, and includes specific content categories, which informs the agent about the returned data's nature without contradicting any annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with zero filler. The first sentence delivers the core action, content list, and default time window. The second and third sentences add scope differentiation and usage guidance, each earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, two-parameter list tool with strong annotations and 100% schema coverage, the description fully covers what the tool returns, its default behavior, and how it differs from close alternatives. No output schema is needed for this simple feed tool, and the description leaves no significant usage questions unanswered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both days and limit already fully described in the schema (including defaults, ranges, and meanings). The description only reiterates the default 7-day window, adding no new parameter-level insight, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('chronological feed of recent Canton Network activity'), enumerating concrete content types (CIP status changes, grant proposals, forum threads, blog posts, GitHub releases, radar items). It explicitly differentiates itself from a git/repo changelog and from get_trending, leaving no ambiguity about its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: "Use for 'what changed/happened on Canton recently'" and directly names the alternative: "use get_trending instead for popularity-ranked 'what's hot'." It also states a clear exclusion ("Not a git/repo changelog"), making the tool's suitable context unmistakable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, but the description adds valuable behavioral detail beyond that: the data source (sv_operations_calendar), the filter on operation_type (deploy|release|upgrade), and the cross-referencing with github_releases for SemVer-like tags. This enriches the agent's understanding without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the core purpose, then add the use case. Every phrase carries meaning; no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema), the description covers the essential context: data source, filtering logic, scope, and intended query. It is fully adequate for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both 'limit' and 'offset' are thoroughly documented with defaults, ranges, and behavior. The description adds no direct parameter-level detail, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves recent completed SV deployments/releases from sv_operations_calendar, cross-referenced with github_releases. It specifies the scope (Canton-specific) and the exact use case ('what shipped on MainNet recently?'), distinguishing it from siblings like get_latest_release or get_upcoming_operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly gives a usage context: 'Use to answer "what shipped on MainNet recently?"'. While it doesn't name alternatives or exclusions, the use case is clear enough to guide the agent when to choose this over other deployment/release tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe to invoke. The description adds useful context: what it returns (keywords/error codes) and the filtering logic (distinct months), which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose and scope, no redundant information. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains the return value (keywords/error codes) and the domain (Canton/Daml/Splice). It is complete enough for the agent to decide usage, especially given the tool's simplicity and lack of output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for min_months and window_months. The description mentions defaults (3 months, 18 months) but does not add new meaning beyond the schema, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it identifies recurring error patterns across SDK/release windows, returns keywords spanning at least 3 months over 18 months, and targets Canton/Daml/Splice ecosystem. It effectively distinguishes from siblings like get_issue_status or find_known_issues.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains it's useful for triage prioritization and runbook creation, implying when to use it. It does not explicitly exclude alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds moderate value by stating the return format (rendered body with link) but does not discuss auth, rate limits, or side effects beyond mutation hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two sentences that front-load the action, scope, and output. Every word earns its place; no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with full annotations, the description adequately covers the return value and scope. However, the phrase 'Canton-specific' slightly contradicts the listing of multiple repos, causing minor ambiguity. Otherwise, it's complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already explained in the input schema. The tool description reiterates 'version' and 'repo' implicitly but adds no new semantic detail, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action: 'Fetch the release-notes body for one SDK version' and identifies the exact repos (canton, daml, dpm, splice). It also states the return value (rendered release body with link). This distinguishes it from sibling tools like get_latest_release or search_release_notes, though no explicit differentiation is given.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lacks explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference siblings like search_release_notes for broader queries. The phrase 'Canton-specific' provides some context but is ambiguous given multiple repos.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds behavioral context beyond annotations: it mentions personalization based on background and instructs to ask user first. Annotations already indicate readOnly and idempotent, which the description is consistent with. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is very concise (3 sentences) yet covers purpose, usage, exclusions, and user instruction. No wasted words; front-loaded with main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description provides complete context: what it does, when to use, what not to use, how to interact (ask background). No missing information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers the single parameter completely with enum values and description. The description reiterates the instruction to ask background but adds minimal new meaning. Baseline 3 is appropriate as schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool generates a personalized Canton Network onboarding path, using specific verb 'generate' and resource. It distinguishes from siblings like search, get_faq, and get_api_reference by scoping to Canton-only and specifying usage contexts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides usage conditions: 'Use when a developer asks how to start building... Do not use for onboarding to other chains... Prefer this over 'search'... use get_faq for a single specific gotcha and get_api_reference for API details.' Also instructs to ask user's background first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, idempotent, non-destructive), the description adds that the tool returns a schedule of planned events filtered by environment, sourced from a specific feed. This gives the agent insight into the data scope and refresh characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with no wasted words. The first sentence inventories content and source; the second gives usage examples. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description still covers the tool's purpose, data source, event types, and filtering. It could mention the return format (e.g., list of events) but the examples imply that. Overall it is complete for a straightforward read-only list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have descriptions in the input schema (100% coverage), so the description adds little beyond what is already structured. The text mentions 'Filter by environment' which aligns with the environment parameter, but does not elaborate on limit or upcoming_only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('Show') and a clear resource ('Super Validator operations schedule from the Canton Foundation's feed'). It lists concrete event types (releases, deploys, upgrades, governance windows, freezes) and distinguishes itself as 'Canton-specific' 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides two example queries ('what is happening on MainNet next?', 'when is the next Splice cut?') that indicate when to use the tool. However, it does not mention when not to use it or suggest alternative tools among the many siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing safety. The description adds that the snapshot is from CCPEDIA's sync and not a live feed, which is useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loads the purpose and data fields, and wastes no words. Each sentence adds distinct value: what, scope/alternatives, and data source.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and simple functionality, the description covers all needed context: what data is returned, the single asset scope, the cached nature, and alternative tools. No gaps are evident.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is 100% (vacuously). The description implicitly conveys no input is needed, which is sufficient. With zero parameters, a baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool retrieves a market snapshot for CANTON COIN (CC) only, listing specific data fields (USD price, 24h change, market cap, volume, TVL). It clearly distinguishes itself from general crypto-price tools, leaving no ambiguity about scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit guidance: 'Canton-specific. Cannot price BTC, ETH or any other asset (use a general crypto-price MCP like CoinGecko for those).' This tells the agent exactly when to use this tool and when to choose an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context about the ranking criterion (engagement score) and scope (Canton-specific). Minor gap: does not mention whether the data is real-time or cached, but overall most important traits covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, no wasted words. First sentence defines the tool, second provides usage guidance and sibling differentiation. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and good annotations, the description is complete for this simple tool. It clearly defines what the tool returns (trending content) and how to use it, without needing additional details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has 0 parameters, so baseline is 4 as per guidelines. No additional parameter description is needed, and description does not add anything about parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves trending Canton Network content ranked by engagement score, using the verb 'get' and specifying the resource. It distinguishes itself from sibling 'get_recent_changes' by contrasting chronological vs. trending purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when to use: for 'what's hot/popular on Canton right now', and when not: use 'get_recent_changes' for chronological feed. This gives direct guidance and an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so safety is clear. Description adds valuable behavioral detail: events with unidentifiable networks are excluded (not guessed) to avoid wrong deadlines. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: 4 sentences, each earning its place. First sentence states main purpose, second usage scenario, third behavioral note, fourth alternatives and scope. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description covers what the tool returns (types of deadlines), filtering options, network exclusion policy, and alternative tools. No output schema exists, but the description provides adequate context for an agent, though it could mention any pagination or format details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good parameter descriptions (days with min/max/default, environment with options, validator_only boolean). Description mentions 'per network' but does not add significant semantic detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it retrieves Canton operational deadlines (scheduled upgrades, version raises, etc.) and distinguishes from siblings like get_upgrade_status and get_sv_schedule. The verb 'get' and resource 'upcoming deadlines' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use case ('what do I have to do in the next N days'), environment filtering, and when to use alternatives (get_upgrade_status for version-specific verdict, get_sv_schedule for full history). Provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds context about being Canton-specific and covering all environments/types. No hidden behaviors like auth or pagination are mentioned, but annotations cover the safety profile well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, front-loaded with key purpose. Every word earns its place, making it highly efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and good annotations, the description is sufficient to understand scope and intent. Lacks output details, but as a convenience wrapper, the context is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single 'days' parameter with its own description. The description only echoes 'next N days' without adding syntax or additional meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies it as a convenience wrapper for SV operations in the next N days, Canton-specific, targeting validator/SV ops. It distinguishes from siblings like get_sv_schedule by being a quick overview wrapper.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states its use case ('Quick answer for what to be ready for this week'), but does not specify when not to use it or mention alternative tools. The context implies its niche, but no exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating a safe read-only operation. The description adds behavioral context by listing specific reported items (e.g., below minimum, releases behind, next topology freeze times), which goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, the first being a bit long but packed with information. It is front-loaded with the main verb and resource. Could be slightly more concise, but it earns its content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description compensates by listing specific output fields (minimum in force, releases behind, topology freeze, LSU times, min dar versions, breaking changes). This provides sufficient context for the agent to understand what the tool returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already documented. The description adds extra meaning: for 'version', it clarifies 'Omit to get the schedule without a verdict', and for 'environment', it ties to the network context. This adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Upgrade Copilot for a Canton validator', specifying the verb (report/upgrade copilot) and resource (Canton validator upgrade status). It lists specific outputs and distinguishes itself as Canton-specific, differentiating 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides usage examples: 'Use when an operator asks 'am I safe to skip this week?', 'what breaks if I upgrade?', or 'when is my next deadline?''. This gives clear context. It does not explicitly mention when not to use, but the examples are sufficiently directed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing safety. The description adds useful behavioral context beyond annotations: the data source ('derived from the DSO validator licenses on the public Scan API') and the nuance that the Splice version is self-reported and potentially stale, which is important for interpreting results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but efficiently organized. It front-loads the core purpose, then gives use cases and sibling alternatives, and ends with scope. Every sentence serves a purpose, though it is slightly longer than ideal due to the detailed use-case enumeration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description compensates by enumerating the returned data fields (sponsor, version, staleness, last activity, earning range, missed coupons). It also covers use cases, scope, and alternative tools, making it fully self-sufficient for an agent to decide when and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both parameters (name, limit) already well described in the schema. The description's mention of 'by name or party id' adds no new information over the schema's parameter description. Baseline of 3 is appropriate since the schema carries the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a specific verb+resource: 'Look up an individual Canton validator node in the DSO registry by name or party id'. It clearly distinguishes itself from sibling tools like get_validator_fleet and get_upgrade_status by specifying alternative tools for different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit usage guidance is provided: 'Use for "is node X still live", "who sponsors X", "how reliable is X".' It also names alternatives for related but different use cases (get_validator_fleet, get_upgrade_status, list_votes_by_sv) and states the scope limitation 'Canton ecosystem only.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds critical behavioral context: versions are self-reported, stale, and the tool returns freshness count. This is beyond annotations and fully disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured: purpose first, then usage, then caveats. Every sentence adds unique value, though slightly verbose. Could be slightly trimmed but still effectively front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains what the tool returns (version distribution, freshness count, position classification). It also specifies ecosystem and caveats, making the output predictable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'version' has a schema description, but the description adds meaning by explaining its effect (with vs without) and providing an example. Schema coverage is 100%, so the description enhances understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reports the DSO-approved validator fleet version distribution and can show the whole distribution or the user's position relative to other operators. It also distinguishes from the sibling tool get_upgrade_status, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance: call with no version for whole distribution, with version for position. It also tells when to use an alternative (get_upgrade_status for pass/fail rules) and restricts to Canton ecosystem. This provides clear when-to-use and when-not-to-use information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.