SHAR Public Knowledge MCP

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that results are 'source-backed' and scoped to four methods, but it does not disclose output structure, language behavior, or other operational 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 a single, efficient sentence with no filler or redundant restatement. It is slightly vague in wording but structurally sound and front-loaded with the key action and scope.

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 required methods parameter is reasonably self-explanatory, but the description leaves the return format unclear and omits the locale parameter entirely. Since there is no output schema, the agent receives minimal information about what 'capability context' actually contains.

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 0% schema description coverage, the description needed to explain both methods and locale. It only restates the four method enum values and says nothing about locale, which has a default of 'ru' and would affect what the agent should expect in the response.

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 ('Return') and references a concrete resource: source-backed capability context for AI, CGI, live-action, and hybrid methods. It distinguishes itself from the get_* siblings by focusing on production-method comparison, though 'capability context' is somewhat vague and comparison is not explicitly named.

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 gives no guidance about when to use this tool versus alternatives such as get_media_provenance or search_knowledge. The intended usage is only implied by the tool's name and title, with no explicit context or 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?

The annotations already communicate that the tool is read-only, idempotent, and non-destructive. The description adds the return concept but provides no extra behavioral context such as output structure, locale sensitivity, or any side effects. 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 a single, front-loaded sentence with no filler. Every word contributes to understanding what the tool returns.

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 tool is simple and the annotations cover safety, but there is no output schema and the description does not specify the shape of the returned fields or how locale changes the result. It is minimally adequate but leaves small 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?

Schema description coverage is 0%, and the description does not mention the locale parameter or its effect on the returned fields. The schema itself does document the enum and default, so the parameter is not completely opaque, but the description adds no parameter-level meaning.

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 "Return" and identifies the resource: the fields needed to prepare a structured production brief. This makes the tool's purpose clear, though it does not explicitly distinguish it from sibling tools such as get_deliverables.

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 intended use is implied by the resource name and description: retrieving fields needed for a production brief. However, there is no explicit guidance on when to prefer this tool over siblings, when not to use it, or how locale affects the output.

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, so the safety profile is covered. The description adds useful context by saying the case must be 'published' and that the result includes 'typed public facts,' but it does not disclose behavior for missing IDs, response shape, or any limitations.

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 with no filler. It states the action, the resource, and the key scope detail ('published') 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?

For a simple one-parameter read-only lookup with strong annotations, the description is mostly sufficient for invoking the tool. However, with no output schema, the meaning of 'typed public facts' is left vague, and there is no hint about using search_cases to discover a caseId.

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 has zero description coverage and only one parameter, caseId, so the description should compensate. It implies that caseId identifies a published case, but it does not explain the ID format, how to obtain it, or how 'typed public facts' relates to the parameter. The parameter name is self-explanatory enough to make this minimally adequate.

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 ('Retrieve') and names the resource ('one published case' plus 'its typed public facts'), making the tool's basic function clear. 'One' implicitly distinguishes it from search_cases, but it does not explicitly differentiate itself from the many other get_* sibling tools, so it stops short of a 5.

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

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

The description gives no guidance about when to use this tool versus siblings like search_cases or get_public_evidence. There is no mention of prerequisites, such as needing a known caseId, or any exclusions. Usage context is only implied by the parameter and title.

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, idempotentHint, and non-destructiveness, so the safety profile is covered. The description adds minor scoping ('published', 'canonical service') but does not disclose return format, pagination, auth needs, or error behavior. It is consistent with the annotations and does not contradict 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, front-loaded sentence with no filler. It adds the qualifiers 'published' and 'canonical' beyond what the title alone conveys. It is concise, though somewhat under-specified; the structural style itself is sound.

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 lack of an output schema, 0% parameter coverage, and a large set of sibling tools, the description leaves important gaps. It does not explain what 'deliverable context' includes, how serviceId is sourced, or when this tool should be preferred over related get_* tools. An agent would likely need external context to invoke it confidently.

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 schema description coverage at 0%, the description must compensate for missing parameter explanations, but it does not. It only vaguely hints that serviceId refers to a 'canonical service' without explaining how to identify or format it. The locale parameter's behavior and default are left entirely to 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 and resource: 'Return published deliverable context for a canonical service.' It clearly identifies what the tool returns and distinguishes it from sibling tools by focusing on deliverables rather than prices, cases, facts, or other resources. However, it does not explicitly differentiate itself from siblings by name, and 'canonical service' is somewhat unexplained.

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 is provided about when to use this tool versus alternative sibling tools. The description does not mention scenarios, exclusions, or alternatives, and there are many similarly named get_* tools. The 'published' qualifier implies some limitation, but it is not developed into actionable usage 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 readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful context about the source ('published cases') and match semantics ('mention'), but it does not disclose response shape, pagination behavior, or whether matching is exact.

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?

A single 10-word sentence that front-loads the action and resource. No wasted words and the key scope ('published cases that mention...') is immediately clear.

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 lookup with annotations covering safety, the description is mostly sufficient. It omits what the returned cases look like and how industry matching works, which matters more because there is no 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 0% schema description coverage, the description must carry semantic weight. 'Requested industry' clarifies the purpose of the required industry parameter, but limit is not described and match behavior is left unspecified. The schema's name, default, and bounds make limit largely inferable, so this is adequate but not strong.

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 names a specific action ('Find') and resource ('published cases') filtered by industry, so its purpose is clear. It stops short of explicitly differentiating itself from siblings such as search_cases or get_case, though the industry focus is a strong implicit cue.

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 is given on when to choose this tool over alternatives like search_cases or get_case. The agent must infer from the tool name and sibling list that this is the industry-experience-specific 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 declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds a useful behavioral guarantee—that no provenance is fabricated and only genuine published records are reported—which gives the agent confidence in result authenticity. However, it does not describe return format, error behavior, or handling of missing/unknown mediaIds.

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 with no filler or unnecessary detail. The main purpose is front-loaded, and the second clause reinforces a key reliability guarantee. It is concise, though it sacrifices helpful 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?

For a tool with no output schema and no parameter descriptions, the description is too thin to be fully complete. It fails to explain what the returned provenance records look like, whether mediaId is required, or when this tool should be preferred over sibling tools. The authenticity guarantee is nice but does not fill these operational 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?

Schema description coverage is 0%, so the description must compensate by explaining the parameter. It does not mention mediaId at all. The schema only provides type and length constraints, which is insufficient when the description itself adds zero parameter meaning.

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 ('Report') and resource ('genuine published provenance records'), clearly indicating the tool retrieves provenance data for media. It goes beyond a tautology by stating the scope and authenticity guarantee. However, it does not explicitly differentiate this tool from sibling tools or mention the mediaId input.

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 such as get_public_evidence or get_timeline_context. There is no stated context, prerequisite, or exclusion. This is a clear 'no guidance' case.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'canonical' and 'public' context, which hints at authoritative and publicly scoped facts, but it does not disclose additional behavioral traits such as response shape, rate limits, or authentication requirements.

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?

A single sentence delivers the essential action and resource without repetition or filler. The key term 'canonical SHAR identity' is front-loaded, and no sentence is wasted.

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 zero-parameter, read-only retrieval tool with strong annotations, this description is mostly complete: it names what is returned and implies a non-destructive, stable lookup. It does not explain what SHAR identity means or enumerate the organization facts, but the simplicity of the tool limits the severity of that 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 tool has zero parameters and the schema fully documents that with an empty properties object. Per the rubric, a zero-parameter tool receives a baseline of 4, and no parameter-level description is 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 states a specific verb ('Retrieve') and a specific resource ('canonical SHAR identity and public organization facts'), making the tool's core purpose clear. It reads distinctly from siblings like get_public_clients and get_industry_experience, though it does not explicitly contrast itself with any sibling.

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 is provided about when to use this tool versus alternative get_* tools in the sibling list. There are no exclusions, conditions, or mentions of alternatives, leaving the agent to infer usage purely from the name and one-line description.

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, covering the safety profile. The description adds contextual scope but does not disclose additional behavioral traits such as output format, error behavior, or authorization needs. No contradiction with annotations exists.

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 efficient sentence that front-loads the core action and adds a meaningful distinction in the second half. Every word 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?

For a simple read-only, one-parameter getter, the description plus the schema are largely sufficient. It names the return concept, clarifies the scope, and annotations cover the behavioral safety profile. A slightly more complete description could explicitly tie serviceId to the price lookup, but the tool is simple enough that this is a minor 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 a single serviceId parameter with 0% description coverage, and the description does not mention this parameter or explain what values it expects. The tool name and title imply that serviceId identifies the service, but the description itself fails to compensate for the missing schema description.

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 'Retrieve' and the specific resource: the accepted current starting price. It also sets it apart from historical case budgets, which helps distinguish its scope even though no sibling tool is explicitly named.

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 when to use the tool by emphasizing 'current' and 'distinct from historical case budgets,' but it never explicitly states when to prefer this over sibling tools like get_case or get_service. The guidance is present but only implicit.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to cover basic safety behaviors. The description adds the 'owner-approved' filter as a scope qualifier, but does not disclose any additional behavioral traits such as auth requirements or rate limits. No contradiction with annotations exists.

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 front-loads the action, target, and scope. There is no unnecessary repetition or filler, making it highly 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 straightforward read-only retrieval with one optional parameter, the description plus the schema and annotations provide a workable contract. The lack of an output schema and the absence of explicit return-shape details are minor given the simple nature of the tool, but adding them would make it fully 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 schema has 0% description coverage for the only parameter, 'limit', and the tool description does not mention it at all. Because the description was expected to compensate for the low schema coverage, this is a gap even though the parameter's name and constraints are relatively self-explanatory.

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 ('public client relations') with a clear scope modifier ('only owner-approved'). This clearly distinguishes it from sibling get_* tools such as get_public_evidence or get_organization_facts.

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 it should be used when owner-approved public client relations are needed, but it does not explicitly state when to prefer this tool over siblings or when not to use it. No alternatives or exclusions are mentioned, so the guidance is only implied.

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 cover read-only, idempotent, and non-destructive behavior. The description adds the contextual detail that only 'published' evidence records are returned and that the identifier is stable. It does not disclose pagination, ordering, or error behavior, but the annotation coverage lowers 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 is a single focused sentence with no redundancy. It front-loads the action and resource, and every word contributes meaning.

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 only one required parameter, the description plus annotations and schema provide enough information for correct invocation. The absence of an output schema is mitigated by the straightforward nature of the operation. Slight gaps remain around expected response format and pagination behavior, but these are minor here.

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 0%, so the description must compensate. It does clarify that subjectId is a claim or case stable identifier, which is useful beyond the schema. However, the 'limit' parameter is not mentioned at all, though its name and schema constraints make its purpose reasonably inferable.

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 ('Retrieve') and resource ('published evidence records'), and clarifies the target ('a claim or case stable identifier'). It is clear and distinct from sibling tools, though it does not explicitly contrast itself with them.

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 states what the tool does but gives no guidance on when to choose it over siblings like get_media_provenance, get_case, or search_cases. There are no explicit context cues, exclusions, or alternative tool references.

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 disclose read-only, idempotent, non-destructive behavior. The description adds only the selection semantics ('canonical', 'stable identifier') and no extra operational detail such as error behavior or canonicalization implications.

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?

One sentence, front-loaded with the verb and resource, with no filler. Every word ('one', 'canonical', 'stable identifier') carries meaning.

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 one-parameter read with rich annotations, the description is nearly adequate, but it never explains what a SHAR service is or what the returned service entity contains. With no output schema, a bit more return context would make it self-sufficient.

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 sole parameter serviceId has no schema description, so the description must carry the semantic weight; 'stable identifier' tells the agent the ID is stable and canonical but not its format, source, or how to discover it. This is partial compensation for a simple one-parameter tool.

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 ('Retrieve') and resource ('canonical service'), and specifies lookup by stable identifier, so the tool's action is clear. It doesn't explicitly differentiate from siblings like list_services or get_case, but the singular canonical service + stable identifier wording implies direct ID fetch.

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 phrase 'by stable identifier' sets a clear prerequisite: use this when you already have a stable service ID. It gives no explicit guidance on when not to use it or which sibling to prefer for browsing/searching.

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 convey readOnly, idempotent, and non-destructive behavior. The description adds useful context about returning only published information and explicitly not promising a project schedule, which helps set expectations 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 a single focused sentence with no filler. The main action and key caveat are front-loaded in a way that is 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?

With no output schema, no parameter descriptions, and no usage guidance, the description is too thin for an agent to confidently invoke this tool. It explains what is returned at a high level but not what the query should contain, how results are shaped, or when this tool is the right choice.

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 0%, and the description does not explain the 'query' or 'limit' parameters. The schema provides basic constraints, but the description adds no meaning about what a valid query is or how limit affects results, so it fails to compensate for the coverage gap.

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 ('Return') and identifies a specific resource ('published service and case timeline context'). The qualifier 'without promising a project schedule' adds useful scope, but it does not explicitly differentiate this tool from siblings like get_case, get_service, or search_cases.

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 such as get_public_evidence, get_case, or search_cases. It hints at a distinction (timeline context, no schedule promise) but never states the intended use case or exclusion conditions.

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 minor context with 'canonical' and 'stable identifiers,' but does not disclose practical behaviors such as pagination, locale effects, ordering, or response shape.

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 that immediately states the action and object. Every word contributes meaning, with 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?

The description is too sparse for a tool with two undocumented parameters and no output schema. It omits how limit and locale affect results, what a 'stable identifier' means in practice, and how this listing relates to subsequent get_service calls.

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 0%, and the description does not compensate by explaining the limit or locale parameters. An agent must infer their meaning from names alone, which is insufficient for correct invocation.

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

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

The description uses a specific verb ('List') and names a resource ('canonical service catalog and stable identifiers'), making the core function clear. It does not explicitly contrast with the sibling get_service, but the plural list vs singular get is a reasonable implicit distinction.

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 gives no guidance on when to use this tool versus alternatives like get_service or search_knowledge. There is no mention of prerequisites, typical use cases, or conditions that would make this tool preferable.

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 fully captured. The description adds the 'published public' scoping constraint, which clarifies the data domain but does not disclose additional behavior such as pagination, result ordering, or locale effects.

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 short sentence, which is concise, but it sacrifices substance for brevity. It front-loads the main scope but fails to include any additional useful detail, making it more under-specified than efficiently 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?

With no output schema and no parameter descriptions, the description must provide enough context for correct invocation, but it only gives a minimal scope statement. It does not explain what a 'case packet' contains, how results are returned, or how this tool differs from the 14 sibling tools, leaving a substantial information 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?

Schema description coverage is 0%, meaning the input schema provides no descriptions for query, limit, or locale. The description does not compensate by explaining any of these parameters, their defaults, or the meaning of locale choices. This leaves the agent with no semantic guidance beyond parameter names.

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 (Search) and the resource scope ('published public case packets'), which is specific enough to distinguish from the broader search_knowledge tool. However, it does not explicitly name any sibling alternatives to reinforce differentiation, so it falls short of a 5.

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

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

The phrase 'Search only published public case packets' implies a scope restriction but provides no explicit when-to-use or when-not-to-use guidance. It does not reference any sibling tools such as search_knowledge or get_case, leaving the agent to infer the tool's niche from its name and title alone.

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 context by specifying 'canonical' and 'source lineage,' but it does not explain result behavior, pagination, or locale effects. 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?

A single sentence with no filler, front-loading the verb and resource. 'Canonical' and 'source lineage' add useful nuance without bloat.

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 tool is simple, but with no output schema and no parameter guidance, the description leaves some gaps. It clarifies what is searched and the provenance feature, but not what results look like or how query/locale/limit affect the response. Adequate but not 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 0%, so the description needed to compensate by explaining query, limit, and locale semantics. It does not mention any parameter; it relies on the self-explanatory parameter names. The locale enum and query matching behavior remain undocumented.

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, 'Search,' and names the resource: 'canonical public services, cases, and claims with source lineage.' This differentiates it from narrower siblings like search_cases, though it doesn't explicitly name an alternative. The scope is clear and actionable.

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 broad lookups across public services, cases, and claims, but it does not explicitly state when to choose this over search_cases or other sibling search tools. No exclusions or alternative routing guidance is provided, so usage context is only implied.

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