Real-time Model Context Protocol (MCP) server for Italian public grants, incentives, and financing (PNRR, MIMIT, Invitalia, SIMEST, Regional FESR, and Chambers of Commerce CCIAA). Enables AI agents to search 125+ active verified Italian business tenders, evaluate company eligibility, and retrieve official funding details.
Scored across 6 tools
Each tool has a clearly distinct role: bandi search vs. bandi detail, CORDIS project search vs. consortium detail vs. aggregate stats, and company matching. The get_cordis/search_cordis/get_bando/search_bandi prefixes make boundaries easy to infer.
All names use snake_case with a leading verb (get_, search_, match_), which is consistent. Minor deviations come from mixing Italian domain nouns (bando, bandi) with English/CORDIS terms and from slightly uneven noun phrasing such as get_bando_details vs. get_cordis_stats.
Six tools is well-scoped for a focused funding-intelligence server. Each tool covers a meaningful step: discovery, detail lookup, matching, CORDIS search, consortium inspection, and aggregate statistics.
The surface covers the main read-only workflows: search bandi, inspect a bando, match a company profile, search funded CORDIS projects, inspect a consortium, and view aggregate CORDIS stats. A few minor gaps remain, such as a dedicated CORDIS project-detail tool beyond consortium data or richer listing/filter helper tools.
Restituisce la scheda tecnica completa e raffinata di un singolo bando (Clean Fuel per LLM).
Args:
uuid: Identificativo del bando (es. 'mimit-transizione-5-0', 'lombardia-voucher-digitalizzazione-2026')
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Restituisce' implies a read-only retrieval, but the description does not state error behavior, permissions, rate limits, or what happens when the uuid is unknown.
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 purpose is front-loaded in a single clear sentence, followed by a compact Args block for the only parameter. The parenthetical '(Clean Fuel per LLM)' is somewhat unclear, but overall the description is efficient 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?
This is a simple one-parameter retrieval tool, and an output schema already exists, so the description need not explain return values. The main missing context is how to obtain the uuid and any failure behavior, but for a straightforward detail lookup it is largely complete.
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%, but the description compensates well by explaining that uuid identifies the bando and providing concrete examples such as 'mimit-transizione-5-0'. It does not specify format constraints or where the uuid should come from, keeping it short of complete compensation.
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 the verb and resource: it returns the complete technical sheet of a single bando. It distinguishes a single-bando lookup from list/search behavior implicitly, but does not explicitly name search_bandi as the sibling used to find a uuid.
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?
Usage is implied by 'singolo bando' and the required uuid parameter, so an agent can infer this is for fetching details when the identifier is already known. However, there is no explicit guidance on when to use this versus search_bandi or how to obtain the uuid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restituisce i dettagli completi di un progetto Horizon Europe e l'elenco dei partner italiani nel consorzio.
Args:
project_id: ID numerico del progetto CORDIS (es. '101058563')
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the interesting scoping detail that only Italian partners are listed, which is real added context, but it is silent on error behavior for a nonexistent/invalid project_id, on any rate limits, and on what 'complete details' actually encompasses.
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 purpose sentence is front-loaded and contains no filler; the Args block adds the one piece of parameter guidance that matters. Slight redundancy in restating the parameter name, but nothing that wastes an agent's attention.
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?
An output schema exists, so return-value structure need not be spelled out, and the description gives a reasonable summary of what comes back. Still, it leaves ambiguity about whether non-Italian consortium partners are included in the response or excluded entirely, which directly affects whether this tool satisfies 'get the consortium' intents.
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 0% — the schema only says 'Project Id' with type string — so the description must compensate, and it largely does by specifying that the value is a numeric CORDIS project ID and giving a concrete example ('101058563'). It stops short of saying what happens with a non-existent or malformed ID.
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 states a specific verb ('Restituisce') and a precise resource (a Horizon Europe project's full details plus its Italian consortium partners), including the CORDIS domain. It does not, however, differentiate itself from the sibling search_cordis_funded_projects, which an agent could plausibly reach for on the same need.
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?
There is no statement of when to use this tool versus search_cordis_funded_projects or get_cordis_stats, and no prerequisites or exclusions. The only usage signal is implicit: you need a known project_id, which suggests a follow-up call after a search, but that is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restituisce statistiche aggregate sui fondi Horizon Europe attratti da università, centri e PMI italiane.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden, and it only says the result is 'aggregate'. It does not disclose the aggregation dimensions (per year, per region, per beneficiary type), whether figures are totals or averages, or whether the underlying data is a static snapshot, all of which shape how an agent should interpret and present the numbers.
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?
One sentence, front-loaded with the resource and scope, with no filler. Nothing could be removed without losing meaning.
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?
An output schema exists, so the return shape need not be spelled out, and a no-argument read tool has a small surface area. The only real gap is the missing explanation of what the aggregates are broken down by, which the output schema may partially cover.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 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?
States a specific verb and resource: aggregate statistics on Horizon Europe funding attracted by Italian universities, centres and SMEs. The word 'aggregate' implicitly separates it from the sibling tools that return project-level detail (search_cordis_funded_projects, get_cordis_project_consortium), though no sibling is named explicitly.
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?
Usage is implied: reach for this when you want summary figures rather than individual projects. However, the description never states when to prefer it over search_cordis_funded_projects, nor any prerequisites or exclusions, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Esegue il Match-Making automatico per un'azienda: verifica ammissibilità ATECO,
requisiti dimensionali, territoriali e calcola il contributo stimato.
Args:
codice_ateco: Codice ATECO azienda (es. '62.01.00', '62', 'C', '26')
regione: Regione della sede operativa (es. 'Lombardia', 'Lazio', 'Emilia-Romagna')
dimensione_azienda: 'Micro', 'PMI', 'Grande', o 'Startup Innovativa'
investimento_stimato: Spesa prevista in Euro per il progetto (es. 50000.0)
| Name | Required | Description | Default |
|---|---|---|---|
| regione | Yes | ||
| codice_ateco | Yes | ||
| dimensione_azienda | No | PMI | |
| investimento_stimato | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the substantive behavior: which eligibility dimensions are checked (ATECO, size, territory) and that it computes an estimated contribution. It does not state whether the operation is read-only/side-effect-free, whether results come from a fixed catalogue of bandi, or whether the estimate is deterministic. Those are meaningful gaps for an unannotated tool, though the output schema covers the return shape.
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 behavioral summary is front-loaded in a single dense sentence, followed by a compact Args block that earns its space by supplying the parameter examples missing from the schema. No filler or repetition. Slightly verbose in the parameter parentheticals, but nothing extraneous.
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?
An output schema exists, so return values need not be explained, and the description supplies the missing parameter semantics that the 0%-coverage schema lacks. What remains unaddressed is the tool's operational context: whether it evaluates against live bandi, whether it requires any prior search, and whether it is a pure computation. For a four-parameter evaluator this is close to complete.
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, and it largely does: it documents all four parameters with concrete examples ('62.01.00', '62', 'C', '26' for ATECO; named regions; Euro amounts) and enumerates the accepted dimensione_azienda values. It omits the PMI default for dimensione_azienda and the null default for investimento_stimato, and does not say whether the abbreviated ATECO forms are accepted equivalently to the full code.
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 opening sentence states a specific verb and resource: it performs automatic match-making for a company, checking ATECO eligibility plus size and territory requirements and computing an estimated contribution. This is clearly distinguishable from the sibling tools (search_bandi, get_bando_details, get_cordis_*), which are search/lookup tools rather than eligibility evaluation. It stops short of naming a sibling, but the function is unambiguous.
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?
Usage is implied by the purpose: an agent would call this when it wants to know whether a company qualifies for funding and what it might receive. There is no explicit when-to-use/when-not statement and no routing to alternatives such as search_bandi for browsing open calls. The guidance is adequate but inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cerca bandi e agevolazioni pubbliche attive in Italia per parola chiave, regione o tipologia.
Args:
query: Testo da cercare (es. 'digitalizzazione', 'transizione ecologica', 'software')
regione: Filtro geografico (es. 'Lombardia', 'Lazio', 'Emilia-Romagna', 'Nazionale')
tipo_agevolazione: Filtro tipo (es. 'Fondo Perduto', 'Credito Imposta')
status: Stato bando ('Aperto', 'In Arrivo', 'Chiuso')
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| status | No | Aperto | |
| regione | No | ||
| tipo_agevolazione | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and mostly leaves it unaddressed. It does not say whether the search is full-text or exact, how results are ordered or capped, whether pagination exists, or whether a null query returns everything — all relevant for a discovery tool. It also contains a mild tension: it advertises only 'active' grants while the status parameter accepts 'Chiuso'.
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 purpose sentence is front-loaded in a single line, followed by a compact Args block — no filler prose. Minor redundancy in restating parameter names already present as schema titles, but each line adds an example, so it earns its place.
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?
An output schema exists, so return-value explanation is correctly omitted. However, for a four-filter search tool with no annotations, the description says nothing about result volume, ranking, or whether criteria combine with AND or OR — gaps an agent would want to know before calling.
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% (only titles), so the description must compensate, and it does: every one of the four parameters gets both a meaning and concrete example values. It notably enumerates the valid status values ('Aperto', 'In Arrivo', 'Chiuso') that the schema does not declare as an enum, which is real added value.
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?
States a specific verb+resource combination ('Cerca bandi e agevolazioni pubbliche attive in Italia') plus the three filter axes, which is far more informative than the bare name. It does not, however, distinguish itself from the sibling get_bando_details, so an agent must infer that this tool returns a list while that one returns a single record.
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?
Usage is implied by the word 'attive' and by the default status of 'Aperto', giving some sense of the intended default scope. There is no explicit statement of when to prefer this over get_bando_details or the CORDIS search siblings, and no note that all parameters are optional, so the agent must infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cerca progetti Horizon Europe già finanziati dall'UE con partecipanti italiani (CORDIS Intelligence).
Utile per benchmark competitivo, studio degli abstract vincenti e partner search per consorzi.
Args:
query: Parola chiave tecnologica (es. 'robotics', 'clean energy', 'cybersecurity')
only_sme: Se True, mostra solo progetti con PMI o startup italiane partecipanti
city: Filtro per città italiana del partner (es. 'Milano', 'Roma', 'Torino', 'Napoli')
limit: Numero massimo di progetti (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| query | No | ||
| only_sme | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. "Cerca" makes the read-only nature implicit and "già finanziati" tells the agent the data is historical/awarded rather than open calls, but there is no statement on data freshness, coverage limits, or result ordering.
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?
Purpose and use cases are front-loaded in two sentences, followed by a compact Args list. Minimal waste, though "(CORDIS Intelligence)" is a branding tag that adds little for an agent.
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?
With an output schema present, return values need not be explained, and the description covers purpose, use cases, and all four parameters. The remaining gap is sibling differentiation and the behavior of nullable filters, which is meaningful but not fatal for a zero-required-param search tool.
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 Args block does real work: it explains each of the four parameters, including the semantic intent of query ("parola chiave tecnologica"), the SME/startup meaning of only_sme, and Italian-city examples for city plus the default for limit. It does not clarify that all parameters are optional/nullable or what happens when query is omitted, which prevents a 5.
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?
States a specific verb ("Cerca") and resource ("progetti Horizon Europe già finanziati dall'UE con partecipanti italiani"), scoped further to CORDIS. An agent can tell it is a funded-project search rather than a call search, but the description never names the sibling it differs from (search_bandi, get_cordis_stats, get_cordis_project_consortium).
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?
Offers use cases ("benchmark competitivo, studio degli abstract vincenti e partner search") which give implied context for when to reach for it. However there are no exclusions and no routing to alternatives, which matters here because search_bandi (open calls) and get_cordis_project_consortium (consortium detail) overlap conceptually with this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_bando_detailsget_cordis_project_consortiumget_cordis_statsmatch_company_profilesearch_bandisearch_cordis_funded_projects
Add one secure layer between your agents and this server.