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 description need not restate safety. It adds context by specifying the corpus is public and by setting an intended-use boundary, though it does not disclose additional behavioral details such as freshness guarantees or coverage semantics.

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 no wasted words. The action and resource are front-loaded, and the second sentence adds a meaningful intended-use caveat without padding 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 zero-parameter, read-only, idempotent tool with an output schema, this description is complete: it states what is returned, that it is public corpus-level metadata, and the boundary of appropriate use. No additional operational details are needed for correct 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 input schema is empty with 0 parameters and 100% schema description coverage, so there is no parameter documentation burden on the description. The mention of metadata categories helps orient the agent to what the results describe, which is sufficient for a parameterless 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 ('Return'), names the resource ('public corpus'), and enumerates the exact metadata dimensions returned: coverage, source, freshness, and count. This clearly distinguishes it from siblings like search_biomedical_literature or get_publication_details, which operate on searches or individual items.

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 intended-use context ('literature discovery and professional review') and an explicit exclusion ('not diagnosis or treatment'), but it does not explicitly state when to prefer this tool over alternatives. Usage is implied by the corpus-level scope rather than directly contrasted with sibling 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the record being 'complete' and 'public' and about the intended professional-review use case, but it does not add deeper behavioral details such as error handling or corpus freshness. 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 two short sentences with the core action front-loaded. The first sentence states exactly what the tool does, and the second adds a relevant use/limitation note. 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 single-parameter, read-only lookup tool with an output schema and strong annotations, the description is complete. It clarifies the workflow position ('after search'), the scope ('complete public bibliographic record'), and the intended use, leaving no material gap for an agent to safely 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?

The input schema fully documents the pmid parameter, including its format and meaning, so schema coverage is 100%. The description adds no additional parameter-level detail beyond what the schema already states, which is acceptable given the 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?

The description names a specific verb ('Retrieve'), a concrete resource ('one complete public bibliographic record'), and a precise lookup key ('by PMID'). It clearly distinguishes itself from the sibling search and neighborhood tools by focusing on a single-record lookup.

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 'after search' gives clear sequencing context: this tool is a follow-up to a search step, likely search_biomedical_literature. The disclaimer that results are not for diagnosis or treatment provides a relevant when-not-to-use boundary, though it does not explicitly name alternative sibling tools for comparison.

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, so the description does not need to restate safety. It adds useful behavioral context: the neighborhood is 'bounded', and results are intended for discovery/review rather than clinical decisions. 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?

Two short sentences with no filler. The main action is front-loaded, and the purpose/limitation sentence earns its place by clarifying the appropriate use context.

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 tool with a full input schema and an output schema, the description is sufficient. It conveys the essential scope ('bounded neighborhood'), the intended use, and the non-clinical boundary. Missing sibling routing is a minor gap rather than a completeness failure.

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 pmid and from_work_id, including the pattern, optionality, default, and 'reversible graph path' semantics. The description adds no additional parameter detail beyond restating that the operation centers on one PMID.

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 specific verb ('Retrieve'), a specific resource ('bounded citation and semantic neighborhood'), and a precise identifier ('one PMID'). The name and description together clearly distinguish this from sibling tools like get_work_neighborhood (work ID) and get_publication_details (details, not neighborhood).

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 the tool is for literature discovery and explicitly rules out diagnosis/treatment, but it does not name sibling alternatives or state when to choose this tool over get_work_neighborhood or get_publication_details. The primary usage context is clear, yet routing guidance is left to inference.

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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the record is 'complete' and 'public' and restricts usage to discovery/review, but it does not disclose authentication, error behavior, or rate limits; given annotation coverage, this is adequate but not especially rich.

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 filler. The core retrieval behavior is front-loaded, and the second sentence provides a meaningful safety caveat. 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?

For a one-parameter, read-only tool with an output schema, the description is nearly sufficient: it specifies single-record scope, public data, and intended use. The main gap is that it leaves the relationship to the similarly named get_publication_details implicit, which matters given the sibling context.

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 work_id is already documented as a 'Canonical Noodle Literature Corpus work identifier.' The description merely repeats 'Noodle work identifier' without adding formats, examples, or behavioral nuance, so the 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 opens with a clear verb-object pair: 'Retrieve one complete public bibliographic record by Noodle work identifier,' which states exactly what the tool does and the resource it targets. It does not explicitly differentiate itself from the similar-looking sibling get_publication_details, so it stops just short of full sibling 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 a clear intended context ('literature discovery and professional review') and an explicit exclusion ('not diagnosis or treatment'). It does not mention when to prefer an alternative sibling tool, so it lacks explicit routing 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the behavioral detail that the neighborhood is 'bounded'—implying a constrained result set—and the caveat that results are for discovery/review rather than clinical use. 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 exactly two sentences with no wasted words. The action and resource are front-loaded, and the second sentence earns its place by providing a necessary usage limitation.

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 presence of a sibling tool get_publication_neighborhood, the description sufficiently conveys the operation, scope, and intended use. With an output schema and safety annotations present, nothing critical is missing for an agent to invoke this 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%, so both work_id and from_work_id are already documented in the input schema. The description only loosely echoes the main parameter ('one Noodle work identifier') and adds no new semantic detail about parameters, resulting in 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 uses the specific verb 'Retrieve' and names the exact resource: 'the bounded citation and semantic neighborhood around one Noodle work identifier.' This clearly distinguishes it from sibling tools such as get_work_details (which fetches work details) and get_publication_neighborhood (which targets publications rather than works).

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 the intended use case ('literature discovery and professional review') and an explicit non-use case ('not diagnosis or treatment'), giving agents clear context for when this tool is appropriate. However, it does not name sibling alternatives or give explicit routing conditions, so it stops short of full 'when to use instead' 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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the semantic-search behavior and the identifier-anchoring effect, which complements annotations. It does not contradict them, and the additional context is modest but useful.

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 redundant phrasing. The core purpose leads, followed by actionable identifier advice and a clear scope disclaimer. Every sentence earns its place, and the structure is ideal for quick scanning.

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 search tool with a rich input schema (including cursor, sort, limit) and an output schema, the description covers the essential context: semantic nature, identifier anchoring, scope, and usage disclaimer. Nothing an agent needs to invoke it correctly is missing, given the structured annotations already carry safety 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?

Schema coverage is 100% with descriptive text for each parameter. The description essentially restates the query parameter's guidance about including identifiers, so it adds little 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 states a specific verb ('semantically search') and a specific resource ('Noodle's public PubMed-derived biomedical corpus'). This clearly distinguishes the tool from sibling detail/neighborhood tools, 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 advises including known identifiers for exact anchoring, which gives concrete guidance on query formulation. However, it does not explicitly state when to use this tool over siblings (e.g., when you need details for a specific publication, use get_publication_details). The disclaimer about literature discovery implies a use case but lacks explicit when-not 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context beyond those: the action is opt-in, involves no payment or outreach, and changes no scientific result. This meaningfully clarifies what the tool will and will not do.

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 short and front-loads the core purpose in the first sentence. The second sentence adds useful safety/behavioral context, though some phrasing like 'the separate Helena Good MCP' is slightly awkward and could be tighter.

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 informational tool with a provided output schema, the description is largely sufficient. It covers purpose, the informational nature, and the no-payment/no-outreach guarantee. It could be slightly more explicit about when a user would want this information, but nothing critical 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?

The tool has zero parameters, so the parameter-semantics burden is minimal. The description does not need to explain any inputs, and the baseline of 4 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 states a clear action — 'Learn about the separate Helena Good MCP' — and clarifies that this tool is informational, not a payment or outreach mechanism. It is easily distinguishable from the sibling search/get literature tools, though it does not explicitly name any sibling or contrast 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?

It implies the tool is for users who want information about supporting Helena, and it explicitly says no payment or outreach occurs. However, it does not state when to use it versus alternatives or mention sibling tools, leaving the routing decision mostly to inference.

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