Skip to main content
Glama

Sirenic

by eu.sirenic
OverviewDiscussionsAdmin

EU research funding received (CORDIS)

get_french_company_eu_funding
Read-only

EU research and innovation funding received by a French company, from CORDIS (European Commission, CC BY 4.0): every Horizon 2020 (2014-2020) and Horizon Europe (2021-2027) project the company appears in — role (coordinateur, participant, partenaire_associe, tiers…), EU contribution, total cost, dates, project status (signe / clos / termine) and the official CORDIS link — plus totals (projects, EU contribution in EUR, projects under way). The company is matched by the VAT number CORDIS publishes (about 90% of French participations carry a readable one): aucun_financement: true is a NON-conclusive absence, never “never funded”. Facts only, no score. Paid via x402 ($0.02 in USDC or EURC).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sirenYes9-digit SIREN
api_keyNoOptional Sirenic API key (srn_live_…) to pay with prepaid credits instead of x402 — no wallet needed. Get one at https://api.sirenic.eu/compte. Ignored when x_payment is provided (the signed payment wins). On insufficient balance the tool returns a credits error, not an x402 quote.
x_paymentNoOptional signed x402 PAYMENT-SIGNATURE header value. Omit to receive the payment quote.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNoHow to settle the quote, present when payment_required is true.
quoteNoThe signable x402 payment requirements when payment_required is true: {x402Version, accepts[]} where each entry carries scheme, network, amount, asset and payTo (USDC and EURC options at the same numeric amount). Sign one entry and call again with `x_payment`.
resultatNoThe endpoint's JSON response when payment_required is false. Paid responses carry `source`, `disclaimer` and an Ed25519 signature, and every paid JSON response carries a `provenance` array (all tools since 2026-09-06) — one entry per block served, with the official register, licence, version, `as_of` date and `precision_as_of` (what that date means), plus the common per-block envelope: `etat` in a closed list (servi, absence_mesuree, absence_non_conclusive, partiel, perime, indisponible, sans_objet), `motif` when unavailable, `age_jours` (only for publication or ingestion dates), `couverture` (complete / partielle / non_mesurable with its measure) and `confiance` in bands (faible / moyenne / forte, only where a measure grounds it, never averaged across blocks). Read the states before the numbers: an absence_non_conclusive, indisponible or partiel block is never « nothing to report » — only absence_mesuree asserts an absence. Register codes: GET /v1/provenance/registres ; states, closed lists and reading rules: GET /v1/lecture (both free). The PDF tools carry no JSON envelope (the PDF report prints it).
payment_requiredYesTrue when this response is an x402 payment quote instead of data: settle one of the quote's `accepts` options and call the tool again with `x_payment`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description goes further: it discloses the payment mechanism (x402), the VAT matching method, the non-conclusive absence semantics (aucun_financement), and states 'Facts only, no score'. This adds substantial behavioral context beyond the annotations, with no contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but efficient: it front-loads the core purpose, then lists specific output fields, and adds critical caveats (open world, payment) without fluff. It is longer than typical, but every sentence earns its place given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers everything an agent needs to call this tool correctly: data source, matching method, output contents, payment details, the meaning of absence, and licensing. Given the output schema is also provided, no critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and parameter descriptions are already informative (siren, api_key, x_payment). The description adds context about the payment flow (x402 vs api_key) but that is already present in the schema. No extra parameter-level meaning is added beyond what the schema provides, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: retrieves EU research funding data for a French company from CORDIS, with a precise list of fields and totals. It is clearly distinct from all sibling tools, none of which cover EU research funding, so there is no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use it (for EU Horizon funding info about a French company) and even notes the payment method and required SIREN. It does not explicitly name alternatives or say 'use this instead of X', but given its unique scope among siblings, the use case is unambiguous. A minor gap is no explicit exclusion of other funding sources.

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

All Sirenic toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources