Skip to main content
Glama

Oneinfo Search Disclosures

oneinfo_search_disclosures
Read-onlyIdempotent

Search Italian regulated company disclosures from 1INFO, one of Italy's two EU Transparency Directive Officially Appointed Mechanisms (the other is eMarket Storage — use emarket-storage's emarket_search_disclosures for issuers covered there instead, e.g. WEBUILD/SAIPEM). Identify the issuer with company (free-text name, resolved against 1INFO's own 314-issuer list) or ndg (1INFO's internal numeric issuer id, from a prior result) — there is no ISIN field on this source, and LEI only appears embedded in the filename of XBRL-tagged annual-report ZIPs (see the returned document_url for those). BOTH ARE OPTIONAL — omit company/ndg entirely to get every 1INFO issuer's disclosures in the date window in ONE call (the client-side scan then has no ndg to filter on, so every scanned row is a match); cheaper than one call per issuer for a multi-issuer daily check. date_to IS INCLUSIVE (the last local-calendar day you want, Europe/Rome). COVERAGE: 1INFO issuers only — a second Italian mechanism, eMarket Storage, covers a separate set (e.g. WEBUILD) and is not included; an unmatched company name is reported as "not a 1INFO issuer", not as an error. NO SERVER-SIDE ISSUER FILTER exists on this source, so a company/ndg search scans recent storage-date-ordered pages client-side up to a bounded depth — the response's scanned.oldest_date_local says honestly how far back it looked; a rarely-filing issuer may need a narrower/older date_from to surface. fiscal_year is read from the document's own title when it is not an XBRL package (fiscal_year_source tells you which rule produced it — "xbrl_metadata", "title", or "deposit_date_fallback" when the title had no usable year); it is NOT simply the deposit year. Category codes: 1.1=1.1 Relazione finanziaria annuale e relazione di revisione annuale; 1.2=1.2 Relazioni finanziarie semestrali e relazioni di revisione semestrali/revisioni limitate; 1.3=1.3 Pagamento ai governi; 2.1=2.1 Stato membro d'origine; 2.2=2.2 Informazioni privilegiate; 2.3=2.3 Notifiche di partecipazioni rilevanti; 2.4=2.4 Acquisizione o cessione di azioni proprie dell'emittente; 2.5=2.5 Totale dei diritti di voto e del capitale; 2.6=2.6 Modifiche dei diritti inerenti alle categorie di azioni o di valori mobiliari; 3.1=3.1 Ulteriori informazioni previste dalla regolamentazione nazionale; MANTRA=MANTRA — Internal Dealing (operazioni di persone rilevanti e strettamente associate); MANRSS=MANRSS — Relazione sulla gestione, inclusa la dichiarazione di sostenibilità; REGEM=REGEM — Altre informazioni regolamentate (art. 82-ter Regolamento Consob 11971/1999); DOAG=DOAG — Relazione finanziaria; DOOS=DOOS — Documenti operazioni straordinarie; DOAL=DOAL — Documenti diversi. Returns disclosure EVENTS (title, company, category, timestamp, document link) — NOT extracted XBRL facts; for annual-report XBRL facts use esef-filings (Italy: ~6 days behind 1INFO). Half-year reports have NO XBRL-facts source anywhere else, since ESEF is annual-only.

Input Schema

NameRequiredDescriptionDefault
ndgNo1INFO's internal issuer id, e.g. "484" (IREN). Use the value returned by a previous company search to skip name resolution.
limitNoNumber of disclosures to return (1-50). Default 10.
offsetNoResult offset for pagination within the already-scanned match set. Default 0.
companyNoFree-text issuer name, e.g. "SOMEC", "IREN". Resolved against 1INFO's own 314-issuer picklist (name match, not a fulltext search). If it matches more than one issuer equally well, the response lists the candidates instead of guessing — retry with ndg.
date_toNoOnly disclosures published on or before this date (YYYY-MM-DD, Europe/Rome calendar date, INCLUSIVE — the last day you want included).
categoryNoCategory code to filter by, e.g. "2.2" for Informazioni privilegiate. This is the one filter 1INFO's own API honors server-side. See the tool description for the full code list. A row can carry more than one code (e.g. "1.2,2.2"); category_label reflects only the code you filtered on.
date_fromNoOnly disclosures published on or after this date (YYYY-MM-DD, Europe/Rome calendar date, inclusive). If date_to is omitted, this tool searches just this one day.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent, but the description adds substantial context beyond them: no server-side issuer filter means client-side page scanning to a bounded depth, scanned.oldest_date_local reports actual coverage, unmatched names return a soft 'not a 1INFO issuer' rather than an error, and fuzzy names return candidate lists instead of guessing. These are exactly the behavioral traits an agent needs.

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?

Purpose and sibling distinction are front-loaded, and each block (identity, inclusivity, coverage, client-side scan, fiscal_year, category codes) earns its place. It is long and dense, but the bulk is high-value operational detail rather than filler; the category code list is verbose yet necessary since there is no enum.

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?

With no output schema, the description carries the full burden and does: it explains returned fields (scanned.oldest_date_local, fiscal_year_source values, category_label), states that it returns events not XBRL facts, and covers coverage boundaries and failure modes. Nothing an agent needs to call or interpret it is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantic value: date_to is inclusive in Europe/Rome, company/ndg are both optional with defined consequences, and there is no ISIN field (LEI only embedded in XBRL ZIP filenames). It also explains multi-code rows and category_label scoping. Slightly repetitive of schema text in places.

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?

States a specific verb and resource ('Search Italian regulated company disclosures from 1INFO') and immediately distinguishes it from the sibling source eMarket Storage and its emarket_search_disclosures tool. An agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Explicit when-to-use rules: name the alternative for WEBUILD/SAIPEM-type issuers, explain that omitting company/ndg returns all issuers in one call and is cheaper than per-issuer calls, and warn that a rarely-filing issuer may need a narrower/older date_from. Also clarifies which tool to use for XBRL facts (esef-filings).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.