Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

foncier_icpe

Declared industrial installations (Géorisques): ICPE registry, or IREP emissions.

op="installations" (default) — the ICPE registry by siret or code_insee: regime (Déclaration / Enregistrement / Autorisation), IED, Seveso, activity state, geolocation, DREAL service, latest inspection reports, and rubriques (nomenclature number, nature, authorised quantity) with rubriques_energie — those whose very activity IS energy use, each with a plain reading: 2910/3110 combustion, 2920/2921 cooling, 4735/1185 industrial refrigeration. Long sheets are capped at 10, energy ones FIRST, and rubriques_tronquees says so. Detects HEAVY INDUSTRIAL SITES when power consumption is masked in Enedis open data — a SOURCED "big consumer" presumption (cite the codeAIOT), NOT a consumption: an authorised quantity is m³ or MW of plant, never kWh.

op="emissions" — the IREP registry: declared emissions per ESTABLISHMENT, with its SIRET and coordinates, by departement, code_insee or siret. The complement to foncier_beges: a GHG inventory covers a whole ORGANISATION and never says where, IREP names WHICH site weighs — and therefore which address to call on. ⚠️ 89% of the registry's quantities are the string "< seuil" (declared BELOW the reporting threshold): they come back as quantite: null with sous_seuil: true, never as zero, sorted after the known quantities. ⚠️ CO2 comes in three labels — fossil (the default), biomass, and the total that sums both; reading the total as fossil inflates a site that burns wood.

A parameter the chosen op cannot honour is REFUSED, never silently dropped. fields keeps only these keys in each record; the envelope always stays.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "foncier_icpe"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNo"installations" (ICPE, default) or "emissions" (IREP).installations
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
pageNo1-based page of 20 (installations only).
anneeNoregistry vintage (emissions only).
limitNoestablishments returned (emissions only).
siretNoestablishment SIRET (14 digits).
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
fieldsNokeys kept in each record.
milieuNo"Air" by default; empty = water and soil too (emissions only).Air
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
polluantNoEXACT dataset label (emissions only); omitted = fossil CO2, "" = every pollutant.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
code_inseeNoINSEE commune code.
departementNoINSEE department code (emissions only).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and discharges it: it discloses the 10-rubrique cap with energy rubriques ranked first plus the 'rubriques_tronquees' flag, and that heavy-site detection is a cited presumption (codeAIOT) and never a kWh consumption. It further warns that '< seuil' quantities return as 'quantite: null' with 'sous_seuil: true' and are sorted after known values, and that CO2 appears under three labels where reading the total as fossil inflates results — non-obvious failure modes an agent would otherwise get wrong.

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 purpose is front-loaded and the two operations are cleanly segmented with warnings grouped after the main statements, so an agent can skim to the relevant op. It is dense and long, with some restatement (the op split is stated, then re-stated per section) and heavy inline emphasis, but for a two-op, fifteen-parameter tool most sentences earn their place.

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?

There is no output schema, and the description compensates by enumerating what an ICPE record contains (regime, IED, Seveso, activity state, geolocation, DREAL service, inspections, rubriques) and what an IREP record contains (per-establishment emissions with SIRET and coordinates). Combined with the truncation, sorting and null-vs-zero rules, an agent has enough to call it and interpret the result correctly.

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%, so all fifteen parameters are already documented in the schema, and that sets the baseline at 3. The description does add real meaning beyond it — 'polluant' omitted means fossil CO2 while "" means every pollutant, 'milieu' empty extends to water and soil, and 'fields' trims records without touching the envelope — but it leaves several parameters (page size 20 vs limit 50, annee vintage, _run_id/_org/_group plumbing) to the schema text.

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 opening states a concrete verb and resource ('Declared industrial installations (Géorisques): ICPE registry, or IREP emissions') and immediately splits it into two named operations with distinct return content. It also routes against the sibling 'foncier_beges' by naming it as the organisation-level complement, so an agent can tell the tools apart without opening a schema.

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?

It states which filters each op honours ('siret' or 'code_insee' for installations; 'departement', 'code_insee' or 'siret' for emissions) and that a parameter the chosen op cannot honour is refused rather than silently dropped, which is actionable routing guidance. It also implies a when-to-prefer-this-over-foncier_beges condition (site-level instead of organisation-level), but gives no exclusions relative to other foncier/urba siblings such as foncier_conso_elec or urba_risques.

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

All Tulina 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