AgentLore

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

Adds 'Requires auth' which is not present in annotations, providing necessary authentication context. However, it fails to describe what 'deep analysis' entails, what the output format is, or the implications of the different goal enum values (compare, deep_dive, etc.).

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?

Extremely concise at two sentences with no filler. However, it may be overly terse given the tool's complexity (3 parameters, 6 goal modes, no output schema), sacrificing necessary context for brevity.

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?

Minimum viable for a tool of this complexity. The annotations cover safety properties (read-only), and the schema documents parameters, but the description lacks domain context (knowledge base entries) and output expectations that would help an agent invoke this 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?

With 100% schema description coverage, the baseline is 3. The description adds no parameter-specific guidance (e.g., explaining what 'entry slugs' are or how the quality setting affects behavior), but the schema carries the full load adequately.

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?

States the action ('Deep analysis and workflow recommendations') but omits the domain/resource being analyzed. Given siblings like get_entry and submit_knowledge, this clearly operates on knowledge entries, but the description fails to specify what the analysis targets.

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 no guidance on when to use this tool versus alternatives like search or get_entry. The 'Requires auth' note is a prerequisite, not a usage guideline for selecting this tool over siblings.

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

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 that the tool 'Returns actionable instructions', which compensates for the missing output schema. It also notes 'verified' status, adding trust context not in 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 zero waste. First sentence establishes purpose, second discloses return type. Efficiently front-loaded with 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 4-parameter read-only tool with full schema coverage, the description is adequate. It proactively mentions the return value ('actionable instructions') despite no output schema being present, which helps the agent understand 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?

Schema description coverage is 100%, with clear descriptions for all 4 parameters including the 'tools' filter options and 'session_id' purpose. The description doesn't add parameter-specific guidance, but none is needed given the comprehensive 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 specific verb 'Find' and resource 'verified skill cards', distinguishing it from sibling tools like 'search' or 'get_unverified_claims'. However, it doesn't fully clarify what constitutes a 'skill card' versus other knowledge types in the system.

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 no guidance on when to use this tool versus siblings like 'search', 'advisor', or 'get_suggestions'. The phrase 'for your task' is too vague to help with tool 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 declare read-only safety (readOnlyHint: true), but the description adds valuable behavioral context: authenticated users receive richer content ('full content + claims') versus unauthenticated users. This auth-dependent data disclosure is useful context not in 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 zero waste: first states the operation, second discloses auth-dependent behavior. Information density is high with no filler 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 retrieval tool with complete annotations and input schema, the description is adequate. It discloses the auth content variation, though it could optionally mention error behavior (e.g., entry not found) or pagination.

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 'slug' and 'full' both documented. The description mentions 'by slug' reinforcing that parameter, but adds no significant semantic detail beyond the schema for the 'full' parameter (description conflates it with auth-gated content). Baseline score appropriate 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 action ('Get') and resource ('AgentLore entry') with the key identifier ('by slug'). It distinguishes from sibling 'get_section' by specifying 'entry' versus 'section', though it could more explicitly clarify this relationship.

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 through 'by slug' (direct lookup), but lacks explicit guidance on when to use this versus siblings like 'search' (for querying) or 'get_section' (for partial content). No mention of when the 'full' parameter should be used.

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 establish the operation is read-only and non-destructive. The description adds the authentication requirement, which is useful context not present in annotations. However, it fails to clarify what 'temporal history' entails (e.g., revision timestamps, change deltas, array format) or pagination behavior, leaving behavioral gaps for a data retrieval tool.

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 at only two sentences with no filler text. The core action is front-loaded in the first sentence. The second sentence ('Requires auth') earns its place as a critical prerequisite, though it could be slightly more specific about the nature of the authentication required.

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 (single required parameter) and presence of safety annotations, the description provides minimum viable context. However, for a 'timeline' retrieval tool, it notably omits what the temporal data structure looks like, what time range is returned, or whether the fact must exist (vs. returning empty history), which would help an agent handle the response 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?

With 100% schema description coverage, the input parameter 'factKey' is fully documented in the structured schema. The description adds no parameter-specific guidance, but the baseline score of 3 is appropriate when the schema already carries the semantic burden completely.

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 ('Get') and resource ('temporal history of a fact'), making the core purpose clear. However, it does not explicitly differentiate from sibling tools like 'get_entry' or 'get_section' that might appear similar to an agent deciding which retrieval tool to use.

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 mentions 'Requires auth,' indicating a prerequisite, but provides no guidance on when to use this tool versus alternatives (e.g., 'get_entry' for current state vs. 'get_fact_timeline' for historical changes) or what conditions necessitate retrieving a timeline over a simple fact lookup.

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 establish readOnlyHint=true and destructiveHint=false. Description adds the authentication requirement ('Requires auth') which annotations don't cover, but omits other behavioral details like error handling when section doesn't exist or return 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?

Extremely concise two-sentence structure with zero redundancy. Every word earns its place: first sentence establishes purpose, second states auth requirement. No filler or unnecessary elaboration.

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?

Adequate for a simple 2-parameter retrieval tool with complete schema coverage and safety annotations. However, lacks guidance on the relationship to 'get_entry' (granularity trade-off) and doesn't address potential error states despite having no output schema to rely on.

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 ('Entry slug', 'Section key'), so parameters are documented in structured form. Description adds no semantic details beyond the schema, warranting the baseline score for high-coverage schemas.

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?

Clear verb ('Get') and resource ('specific section of an entry'). Implicitly distinguishes from sibling 'get_entry' by specifying 'section' rather than full entry, though explicit comparison would strengthen this further.

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?

Only mentions 'Requires auth' but provides no guidance on when to use this versus 'get_entry' (which presumably retrieves full entries) or other siblings. No 'when-not-to-use' or prerequisite context beyond authentication.

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?

While annotations declare this as read-only and safe, the description fails to disclose what the suggestions actually represent (generated vs. cached), how they are produced, or any rate limiting. Unlike the 'get_calls' example which added scoping constraints, this adds no 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 single six-word sentence is efficiently structured with no redundancy. However, it borders on being overly terse given the lack of supporting detail in other fields, though it avoids the tautology trap of simply restating the tool name.

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 safety annotations provided, the description meets minimum viability but leaves significant gaps regarding the nature of the suggestions and return value expectations given the 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?

With 100% schema description coverage ('Entry slug' for entry_slug), the baseline score applies. The description mentions 'entry' which loosely maps to the parameter, but provides no additional semantic detail such as format requirements or examples 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 clear verb ('Get') and identifies the resource ('content suggestions') and scope ('for an entry'). However, it lacks specificity regarding what 'content suggestions' entail (e.g., AI-generated recommendations, editorial feedback) and does not explicitly differentiate from the 'advisor' sibling tool which may offer similar functionality.

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 no guidance on when to use this tool versus alternatives like 'advisor' or 'search', nor does it mention prerequisites such as requiring an existing entry (implied by entry_slug but not stated).

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 the authentication requirement ('Requires auth') which annotations don't cover. However, it omits details about return format, pagination behavior with the 'limit' parameter, or what confidence thresholds mean in practice.

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 short sentences with zero waste: front-loaded with the core action, followed by the auth requirement. Every word earns its place; no redundant phrases or filler 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 the 100% schema coverage and presence of annotations, the description provides minimal viable context. However, it misses opportunity to explain the confidence filtering behavior (that all three parameters are optional and control the 'low-confidence' threshold) or clarify the relationship with the verification workflow.

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 all three parameters (limit, maxConfidence, minConfidence) fully documented in the schema. The description does not mention parameters explicitly, but at high coverage levels, this is acceptable. Baseline score 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 uses specific verb 'Get' with clear resource 'low-confidence claims needing verification', effectively defining the tool's scope. It implicitly distinguishes from sibling 'verify_claim' by positioning these as inputs needing verification rather than performing the verification itself.

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?

While it notes 'Requires auth' as a prerequisite, it provides no guidance on when to use this tool versus alternatives like 'verify_claim' or 'search'. It does not indicate typical workflows (e.g., use this to find claims, then verify them) or when to apply confidence filters.

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 read-only/idempotent safety. The description adds value by specifying that entry counts are included in the returned data. However, it lacks details on pagination, rate limits, or the return format given the absence of an output schema.

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, efficient sentence (7 words) with verb-fronted structure. No redundancy or 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?

Adequate for a simple read-only tool with rich annotations, mentioning the key returned attribute (entry counts). However, without an output schema, it could further clarify the return structure or whether results are paginated.

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?

Zero parameters present. Per rubric, 0 params = baseline 4. No parameter documentation 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?

States specific verb ('List') and resource ('knowledge domains'), with scope detail ('with entry counts'). However, it does not explicitly differentiate from sibling tools like 'search' or 'get_entry' in the text itself.

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 no guidance on when to use this tool versus alternatives. No mention of prerequisites, pagination behavior, or when to prefer 'search' over this comprehensive listing.

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 this is a non-destructive, idempotent write operation (readOnlyHint=false), but the description adds no context about what 'reporting' entails—such as data persistence, user attribution, or impact on future skill recommendations.

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?

Extremely concise at six words with no redundancy. However, the brevity may underserve the tool's functional complexity as part of a feedback loop system.

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?

Insufficient for a 3-parameter feedback tool. Fails to explain the relationship to find_skills, the meaning of outcome states (SUCCESS vs PARTIAL), or the purpose of the reporting mechanism (e.g., improving recommendations).

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 (usage_id source, outcome enum purpose, note optionality). With schema fully self-documenting, the description baseline is adequate at 3, though it adds no additional semantic context 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?

States a clear verb (Report) and resource (skill card helpfulness). Distinguishes from sibling tools like find_skills or get_entry by focusing on outcome feedback rather than retrieval or 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?

Provides no explicit guidance on when to invoke the tool (e.g., after attempting to use a skill) or when not to use it. While the usage_id parameter schema references find_skills, the main description lacks temporal or contextual prerequisites.

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=true and destructiveHint=false, establishing safety. The description adds that it 'Returns entries', indicating the return type structure slightly beyond annotations. However, it omits behavioral details like result limits, ranking logic, or whether matches are exact/fuzzy.

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?

Extremely concise at two sentences with zero redundancy. Front-loaded with the core action ('Search') and resource ('AgentLore knowledge base') in the first sentence. Every word 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?

For a simple 2-parameter read-only tool, the description is minimally adequate. However, without an output schema, it only mentions returning 'entries' without describing their structure, fields, or cardinality (single vs list), leaving significant gaps in understanding the return value.

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 'query' and 'domain' already documented. The description does not add semantic context (e.g., what constitutes a valid 'domain' value, query syntax examples, or search operators). With full schema coverage, baseline 3 is appropriate for no added parameter semantics.

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?

States specific verb 'Search' and resource 'AgentLore knowledge base', clearly identifying the target domain. However, it does not explicitly differentiate from siblings like 'get_entry', 'find_skills', or 'list_domains' which also retrieve information from the same knowledge base.

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 no guidance on when to use this broad search capability versus more specific retrieval tools like 'get_entry' (direct lookup) or 'find_skills' (specialized search). No prerequisites, filters usage, or exclusion criteria 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?

The description adds valuable behavioral constraints beyond the annotations: specifically, the requirement to 'Ask user permission first' and authentication needs. While annotations indicate it's a write operation (readOnlyHint: false), the description clarifies the user-consent workflow not captured in structured fields.

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 three short, front-loaded sentences with zero redundancy. Each sentence delivers essential information: purpose, permission requirement, and authentication, earning its place efficiently.

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 3-parameter schema, absence of output schema, and provided annotations, the description is sufficiently complete. It captures the essential side-effect warnings (permission, auth) necessary for a write operation, though it could optionally clarify submission outcomes or verification workflows.

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 input parameters (title, sourceUrl, sourceText) are fully documented in the JSON schema itself. The description provides no additional parameter guidance, meeting the baseline expectation when the schema is self-sufficient.

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 specific action ('Submit') and target resource ('knowledge to AgentLore'), distinguishing it from sibling read operations like 'get_entry' or 'search'. However, it does not explicitly differentiate from similar write-oriented siblings like 'report_skill_outcome'.

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 prerequisites with 'Ask user permission first' and 'Requires auth', offering clear behavioral guardrails for when to use this tool. It lacks explicit guidance on when to choose this over alternatives but covers critical safety constraints.

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?

The description adds 'Requires auth' which complements the readOnlyHint: false annotation. However, it fails to address the idempotentHint: false annotation—critical information that resubmission may create duplicates or have side effects. No explanation of post-submission outcomes (e.g., claim closure) is provided.

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?

Extremely concise at two sentences. Information is front-loaded with the action verb, and 'Requires auth' provides essential context without verbosity. No redundant or filler 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?

Adequate but minimal given the tool's complexity (6 parameters, non-idempotent write operation). While the schema covers parameters well, the description lacks workflow context regarding sibling tools and output expectations for a submission action.

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 schema adequately documents all 6 parameters (claimId, verdict, evidence, etc.). The description adds no semantic context beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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 core action ('Submit verification or dispute') and target resource ('claim'), distinguishing it from retrieval-focused siblings like get_unverified_claims. However, it fails to differentiate from submit_knowledge, another submission tool in the sibling 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?

No guidance provided on when to use this tool versus alternatives, or prerequisites beyond auth. Given the presence of get_unverified_claims (likely the first step in the workflow), the omission of usage sequence is a significant gap.

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