get_entry

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

With no annotations provided, the description carries the full burden and does well: it discloses the size guard behavior (max_chars replacing large nested fields with summaries), the enhanced variant's query path, and the return shape when attribute is set. It does not mention auth or rate limits, but these are likely irrelevant for a public fetch. The description adds meaningful behavioral detail beyond simple 'fetch.'

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 appropriately structured with a lead sentence, a scope/usage sentence, and separate Args and Returns sections. It is slightly longer than the absolute minimum but every sentence provides useful information, with no fluff or repetition.

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

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

Given no output schema and a 4-parameter tool, the description is highly complete: it explains all parameters, the return format for both normal and attribute modes, the size guard, and the enhanced variant. It also covers the range of supported object types. There are no gaps left for the agent to guess.

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%, but the description compensates fully by explaining each parameter: stable_id with an example, enhanced with its query variant, attribute with concrete examples, and max_chars with its size-guard behavior. This provides complete meaning that the input schema alone lacks.

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

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

The description opens with a specific verb and resource: 'Fetch the full record for any Reactome object by identifier.' It explicitly lists supported entity types (pathways, reactions, physical entities, complexes, regulators) and distinguishes itself from siblings like get_entries (which is plural and likely batch-focused) and get_event_* tools by stating it handles any identifier.

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 clear context on what object types it works for and offers parameter-level guidance ('Use attribute to retrieve a single field cheaply, or enhanced to include indirect references'). However, it does not explicitly state when to avoid this tool or compare it to alternatives like get_interactors or get_complex_subunits, leaving the when-to-use guidance implied rather than explicit.

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