Skip to main content
Glama

Emarket Storage

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Emarket Search Disclosures

emarket_search_disclosures
Read-onlyIdempotent

Search Italian regulated company disclosures from eMarket Storage (Teleborsa), one of Italy's two EU Transparency Directive Officially Appointed Mechanisms. PREFER OVER esef_filing_search FOR ITALIAN ISSUERS COVERED HERE — this source is updated same-day, unlike the community ESEF index which runs months behind. Identify the issuer with company (free-text name, resolved against eMarket's own ~480-issuer list) or azienda_id (Teleborsa's internal numeric id, from a prior result) — there is no ISIN/LEI field on this source. date_to IS INCLUSIVE (the last day you want included) — this tool handles the underlying source's own date_to being EXCLUSIVE by always querying one calendar day past it, so date_from="2026-09-21", date_to="2026-09-22" correctly returns rows from BOTH the 21st and the 22nd; a single date_from with no date_to searches just that one day. COVERAGE: only issuers that disclose through eMarket Storage — a second Italian mechanism, 1INFO, covers a separate set of issuers (e.g. IREN, SOMEC) and is NOT included; use oneinfo-storage's oneinfo_search_disclosures for those. An unmatched company name is reported as "not an eMarket Storage issuer", not as an error. Category codes: 100=1.1 Relazioni finanziarie annuali e relazioni di revisione annuali; 101=1.2 Relazioni finanziarie semestrali e revisioni limitate; 102=1.3 Pagamento ai governi; 103=2.1 Stato membro d'origine; 104=2.2 Informazioni privilegiate; 105=2.3 Notifiche di partecipazioni rilevanti; 106=2.4 Acquisizione o cessione di azioni proprie dell'emittente; 107=2.5 Totale dei diritti di voto e del capitale; 108=2.6 Modifiche dei diritti inerenti alle categorie di azioni o valori mobiliari; 109=3.1 Ulteriori informazioni previste dalla regolamentazione nazionale; 110=MANTRA — Internal Dealing (operazioni di persone rilevanti e strettamente associate); 111=MANRSS — Relazione sulla gestione inclusa la dichiarazione di sostenibilità; 150=REGEM — Altre informazioni regolamentate (art. 65-ter Regolamento Consob 11971/1999). Returns disclosure EVENTS (title, company, timestamp, PDF link) — NOT extracted XBRL facts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cercaNoFull-text search across disclosure titles and attachment contents.
limitNoNumber of disclosures to return (1-24). Default 10. The underlying source pages in fixed blocks of 24; a limit/offset combination that crosses a page boundary returns only the remainder of that page — use has_more and increase offset by 24 to page further.
marketNoExact market/segment name to filter by, e.g. "Euronext Milan", "Euronext STAR Milan", "MTA". Must match eMarket Storage's own market label exactly; omit if unsure.
offsetNoResult offset for pagination. Default 0.
companyNoFree-text issuer name, e.g. "Saipem", "amplifon". Resolved against eMarket Storage's own 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 azienda_id.
date_toNoOnly disclosures published on or before this date (YYYY-MM-DD, INCLUSIVE — the last day you want included). The upstream source's own date_to parameter is EXCLUSIVE of that day, so this tool always adds one calendar day internally before querying; the response echoes both your inclusive date_to and the exclusive bound actually sent upstream.
categoryNoEU Transparency Directive category code to filter by, e.g. "104" for Informazioni privilegiate. See tool description for the full code list. When set, every returned row is tagged with this category (the source does not expose a category on the row itself, only as a search filter — so category is null on unfiltered results).
date_fromNoOnly disclosures published on or after this date (YYYY-MM-DD, inclusive). If date_to is omitted, this tool searches just this one day.
azienda_idNoTeleborsa's internal issuer id, e.g. "1247" (Saipem). Use the value returned by a previous company search to skip name resolution.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, open-world, and non-destructive traits. The description adds substantial context beyond them: coverage limitations (no 1INFO issuers), date_to inclusivity handling, unmapped-name behavior ('not an eMarket Storage issuer'), and return type (events with PDF links, not XBRL facts).

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

Conciseness3/5

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

Front-loaded with purpose, but the description is very long, largely due to the exhaustive category code list (13 entries) which, while necessary for the tool, makes it verbose. Some date_to semantics are repeated from the schema, reducing conciseness.

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?

Given 9 parameters, no output schema, and the complexity of two competing Italian disclosure mechanisms, the description covers coverage scope, date handling, issuer identification, category codes, and return format. An agent has enough context to call the tool correctly.

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 the full category code list (100–150) that is not present in the schema and is required to use the category filter. It also clarifies date_to inclusivity and company resolution nuances already detailed in schema, adding marginal extra value.

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 eMarket Storage.' It distinguishes from sibling emarket_get_disclosure (search vs. get) and names alternative sources (esef_filing_search, oneinfo_search_disclosures) so the agent can identify the right tool without opening schemas.

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?

Explicitly says to prefer over esef_filing_search for Italian issuers covered here and directs to oneinfo_search_disclosures for 1INFO issuers. However, it does not mention the sibling emarket_get_disclosure or clarify when to use this search versus fetching a specific disclosure.

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

All Emarket Storage 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