EU Money

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

The annotations already declare readOnlyHint and idempotentHint for safety, and the description adds what behavior the output has: structured source facts plus clearly identified explanatory guidance. This helps the agent know what type of content to expect, which goes slightly beyond what annotations tell them.

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?

Two precise sentences front-load the usage constraint ('after search') and resource scope, then describe the return type. There is no filler and every word contributes to understanding.

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 present output schema, the safety annotations, and a sibling set that clearly distinguishes a search tool from a render tool, the description is fully sufficient. It also mentions it returns both facts and explanatory guidance, covering the output nature beyond the schema.

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 description fully documents the only parameter, including the specific ID prefix patterns. The description adds nothing material about this parameter beyond the schema, so the baseline 3 applies.

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 both a specific verb (retrieve) and a specific resource (one complete citation-ready EU Money record by ID). It names the distinct record types it handles (grant, draft, topic, or knowledge) and can be told apart from siblings by referring to 'after search' for the ID and returning full complex content.

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 opening sentence 'Use this after search' explicitly positions the tools' usage in the workflow, and the ID parameter confirmation ('ID returned by search') reinforces that operations depend on search results. It doesn't explicitly state exclusion conditions, but the context makes it clear a separate search should be used for exploration before narrowing to fetch.

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

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.

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds useful scope context about returning current/planned opportunities and knowledge articles. However, it does not disclose result volume, pagination, or ranking behavior; 3 is appropriate given 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?

Two sentences, each earning its place: the first establishes the user-intent trigger, and the second gives the sibling-precedence rule. All high-value content is front-loaded.

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 one-parameter read-only search tool with an output schema and clear annotations, nothing essential is missing. The description covers when to invoke it, what it searches, and how it relates to fetch.

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?

There is only one parameter and its schema description already covers language and natural-language format (100% coverage). The tool description contributes context about what kinds of queries are relevant, but it does not materially expand the schema semantics. This earns the baseline score of 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 names a specific verb-resource pairing: search EU Money for Hungarian EU funding opportunities and related knowledge. It also explicitly differentiates from the sibling tool fetch by telling the agent to call search first when no entity ID is known.

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 states exactly when to use the tool ('when the user wants to find...') and provides a clear routing rule ('Call search before fetch when you do not already have an EU Money entity ID'). This is the strongest form of usage guidance.

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