ea_resolve

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

Although annotations indicate readOnly and closed-world behavior, the description goes far beyond that by explaining the matching algorithm in detail: exact GUID matches, name-first matching, prefix fallback, and the guarantee that exact hits are not diluted. It also warns that 'prefix' candidates are inexact and must not be treated as confirmed identities. This is rich behavioral context not available in annotations or 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?

The description is a single dense paragraph but each sentence contributes unique value: the action, matching rules, output structure, warning about prefix, and filtering advice. It is not overly verbose, though the structure could be improved with bullets or headings. It is appropriately front-loaded with the purpose and primary behavior.

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 lacking an output schema, the description fully explains the return format: the echoed 'reference', the 'candidates' array, and each candidate's fields (type, id, name, fullPackagePath, eaGuid, match). It also clarifies the meaning of each match value and the warning about prefix matches. The matching algorithm is completely described, leaving no significant gaps for an agent to correctly invoke and interpret the result.

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

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

The schema already documents both parameters, but the description adds meaningful semantic detail for the 'reference' parameter by explaining the matching rules (exact vs prefix) and how analyst codes like UC_ABC_2079 map to elements. For 'kind', it only restates the filter intent with little added value. Overall, the description enhances understanding beyond the schema, earning above the baseline 3.

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

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

The description clearly states the tool resolves an analyst reference (braced GUID or plain name) to model candidates. It specifies the verb 'resolve' and the resource 'analyst reference', and the matching behavior distinguishes it from a generic search tool. The detailed matching rules make the purpose unambiguous and differentiate it from sibling tools like ea_search.

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

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

The description provides a clear context for when this tool is appropriate: it is used to resolve references to candidates, with explicit guidance on how references are matched (exact, prefix) and a warning about inexact matches. It does not explicitly name alternatives or exclusion conditions, but the resolution-specific behavior makes the use case evident. The optional 'kind' filter is also mentioned as a way to narrow results.

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