render_resultsUse this when one or more EU Money IDs have already been selected and the user wants compact interactive cards. It does not search, submit an application or change any data.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | IDs returned by search |
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, and non-destructive, and the description reinforces this by stating it does not search, submit an application, or change data. It also adds useful behavioral information that the output is compact interactive cards, going slightly beyond the 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 two sentences with no filler. It front-loads the primary use case, specifies the input condition, and briefly states what the tool does not do, which makes it efficient and easy to parse.
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 tool with a single required parameter, a fully described schema, and annotations covering safety profiles, the description provides sufficient context: when to use it, what it takes as input (previously selected IDs), and what it outputs conceptually (compact interactive cards). Nothing essential to tool selection or invocation 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 description coverage is 100%, so the schema already explains that 'ids' must be IDs returned by search and declares minimum and maximum counts. The tool description adds only that the IDs should already be selected, which is high-level context rather than crucial parameter semantics.
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 identifies the tool's purpose: rendering already-selected EU Money IDs as compact interactive cards. It also disambiguates the tool from searching or submitting applications, though it does not explicitly contrast itself with the sibling 'fetch' tool.
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 explicitly states when to use the tool: when one or more EU Money IDs have already been selected and the user wants compact interactive cards. It also lists clear non-uses: it does not search, submit an application, or change data, but it does not name sibling alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct stage: search finds entities, fetch retrieves a complete record by ID, and render_results displays selected IDs as cards. There is no meaningful ambiguity between them.
All tool names use lowercase naming conventions, and search and fetch are clear imperative verbs while render_results follows a verb_noun pattern. The only minor inconsistency is the underscore in render_results versus the bare verbs of the other two.
Three tools is a well-scoped set that exactly covers the search-retrieve-display workflow without adding unnecessary or redundant functions. The count feels naturally complete for the stated purpose.
The server provides a complete read-only research workflow: discover entities via search, fetch full details by ID, and present results interactively. There are no apparent missing operations since the tool does not claim CRUD or application submission capabilities.