Choose SDK method

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that the results are extracted from SDK source and not invented, which is a reliability claim, but it does not describe any side effects, error conditions, or the nature of the return value (e.g., whether it is a lookup, might be empty, or could fail). This is insufficient for a tool with no annotation coverage.

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, compact sentence with no filler. It front-loads the core purpose ('real SDK method(s)') and includes the sourcing detail. It is not verbose, but the phrasing is slightly awkward ('per language extracted...' could be clearer). Overall, it is concise and 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?

Given the absence of annotations, an output schema, and schema descriptions, the description is expected to carry substantial context. It fails to explain the expected input format, what the output looks like, or any dependencies. It does not mention that operationId is required or that language is optional, nor does it clarify what 'one operation' means. The tool is not adequately specified for an agent to call it correctly without further inference.

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 what language and operationId mean. It does not. The schema only provides an enum for language and a generic string for operationId, but the description never clarifies how to obtain or interpret operationId, nor does it explain the per-language aspect. The description adds no parameter-level value, leaving the agent to guess.

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 that the tool returns the actual SDK method(s) for a given operation, per language, sourced directly from SDK source. It distinguishes itself from siblings like get_operation by focusing on SDK method names, but it does not explicitly say what the output format is (e.g., a string, list). The phrase 'never invented by analogy' adds a quality attribute, but the core purpose is understandable.

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_operation or search_knowledge. It does not mention any conditions or contexts where this tool is the right choice, nor does it exclude any scenarios. The only hint is 'never invented by analogy,' which implies reliability but not usage selection.

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