compras_obter_prompt

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

With annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds useful behavior beyond them: it specifies the exact return fields, notes that missing prompts or required arguments produce an '_erro' diagnostic, and states that exceptions are not propagated. 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 front-loaded with the core action, followed by a compact return contract in a code block and a terse error-handling note. It is slightly repetitive ('devolve o texto pronto' / 'conteúdo renderizado pronto para usar') but well-organized and appropriately sized.

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 a 2-parameter tool with 100% schema coverage, an output schema, and rich annotations, the description is complete: it covers return shape, error semantics, and the downstream workflow. Nothing an agent needs to invoke the tool correctly 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?

Schema coverage is 100%, so the baseline is 3. The description only confirms that missing required arguments trigger the error path, while the schema already documents 'nome' and 'argumentos' with examples, types, and constraints.

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-resource pair ('Renderiza um MCP Prompt e devolve o texto pronto') and further defines the output as the content of PromptMessage[0]. This clearly distinguishes the tool from siblings like compras_listar_prompts, which enumerate prompts rather than render 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 gives clear context: after obtaining the rendered text, the LLM normally follows its instructions and invokes other tools. It does not explicitly name alternatives or exclusions, but the parameter schema points to compras_listar_prompts for discovering prompt names, which provides sufficient routing guidance.

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