searchUse this when the user wants to find current or planned Hungarian EU funding opportunities, grant topics, eligibility guidance or EU Money knowledge articles. Call search before fetch when you do not already have an EU Money entity ID.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query in Hungarian or English |
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes |
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.
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.