Verika - Verifica P.IVA, Codice Fiscale e IBAN

Scheda soggetto da partita IVA

scheda_soggetto

Read-onlyIdempotent

Quadro completo di un soggetto italiano a partire dalla partita IVA: controllo formale, stato su VIES con denominazione e indirizzo normalizzato (via, CAP, comune ISTAT, provincia, regione), screening sanzioni UE sulla denominazione, se il soggetto è una Pubblica Amministrazione i dati IPA (codice IPA, PEC, sito), e per le imprese con LEI i dati GLEIF: forma giuridica, stato del LEI, controllante diretta, capogruppo e numero di controllate. Ogni blocco indica la fonte e se il servizio era raggiungibile. Per un'azienda privata la scheda non include soci, cariche o bilanci (dati a pagamento del Registro Imprese).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "partita_iva": "<partita_iva>"
    },
    "name": "scheda_soggetto"
  }
}

Input Schema

Name	Required	Description	Default
`sanzioni`	No	Esegui lo screening sanzioni sulla denominazione VIES (default true)
`partita_iva`	Yes	Partita IVA italiana, 11 cifre, es. '12345678903'

Output Schema

Name	Required	Description
`ipa`	Yes
`vies`	Yes
`gleif`	Yes	Dati LEI (GLEIF); null se la P.IVA è formalmente errata
`formale`	Yes
`sanzioni`	Yes	null se la P.IVA è formalmente errata, se VIES non dà una denominazione o se disattivato
`riepilogo`	Yes	Una frase di sintesi per l'utente

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / partita_iva / description

Previous value: -"Partita IVA italiana, 11 cifre"New value: +"Partita IVA italiana, 11 cifre, es. '12345678903'"

Changed2 schema fields changedOct 10, 2026

addedOutput schema / properties / gleif

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "properties": {
+        "capogruppo": {
+          "anyOf": [
+            {
+              "additionalProperties": {},
+              "properties": {
+                "denominazione": {
+                  "type": "string"
+                },
+                "lei": {
+                  "type": "string"
+                },
+                "paese": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "lei"
+              ],
+              "type": "object"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "controllante_diretta": {
+          "anyOf": [
+            {
+              "additionalProperties": {},
+              "properties": {
+                "denominazione": {
+                  "type": "string"
+                },
+                "lei": {
+                  "type": "string"
+                },
+                "paese": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "lei"
+              ],
+              "type": "object"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "denominazione": {
+          "type": "string"
+        },
+        "errore": {
+          "type": "string"
+        },
+        "fonte": {
+          "const": "GLEIF",
+          "type": "string"
+        },
+        "forma_giuridica": {
+          "type": "string"
+        },
+        "lei": {
+          "type": "string"
+        },
+        "lei_aggiornato_al": {
+          "type": "string"
+        },
+        "numero_controllate_dirette": {
+          "type": "number"
+        },
+        "prossimo_rinnovo_lei": {
+          "type": "string"
+        },
+        "sede_legale": {
+          "additionalProperties": {},
+          "properties": {
+            "cap": {
+              "type": "string"
+            },
+            "comune": {
+              "type": "string"
+            },
+            "indirizzo": {
+              "type": "string"
+            },
+            "paese": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "servizio_disponibile": {
+          "type": "boolean"
+        },
+        "stato_entita": {
+          "type": "string"
+        },
+        "stato_registrazione_lei": {
+          "description": "ISSUED = valido; LAPSED = non rinnovato",
+          "type": "string"
+        },
+        "trovato": {
+          "description": "false se il soggetto non ha un LEI (normale per le piccole imprese)",
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "fonte",
+        "trovato",
+        "servizio_disponibile"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Dati LEI (GLEIF); null se la P.IVA è formalmente errata"
+}

changedOutput schema / required

Previous value: -[
-  "formale",
-  "vies",
-  "ipa",
-  "sanzioni",
-  "riepilogo"
-]New value: +[
+  "formale",
+  "vies",
+  "ipa",
+  "gleif",
+  "sanzioni",
+  "riepilogo"
+]

First observedOct 9, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: each block reports its source and whether the backing service was reachable, which tells the agent to expect partial/degraded results rather than a hard failure, plus an explicit coverage limit for private companies.

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 in the first clause, and the long enumeration is dense but each clause maps to a real output block, so it earns most of its length. It is a single run-on paragraph with heavyweight parenthetical lists, which slightly hurts scannability.

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?

For a multi-source aggregation tool with an output schema and rich annotations, the description covers everything an agent needs: what is aggregated, the failure/partial-result model, that sources are labelled, and where the data stops. Nothing essential 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 description coverage is 100%: partita_iva is documented as 11 digits with an example, and sanzioni is documented with its default-true behavior. The description does not add syntax, format, or edge-case detail about either parameter, so the baseline of 3 applies.

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 names a specific verb-and-resource combination (a complete profile of an Italian entity built from a VAT number) and then enumerates the exact blocks returned: formal validation, VIES status with normalized name/address, EU sanctions screening, IPA data for public bodies, and GLEIF/LEI data. This makes it immediately distinguishable from the narrower siblings (verifica_partita_iva, controlla_sanzioni, valida_partita_iva) 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 Guidelines3/5

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

Usage is implied rather than stated: the breadth of the description suggests 'use this for a full profile', but no sibling is named and no condition for choosing this over verifica_partita_iva or controlla_sanzioni is given. The closing sentence does set a scope boundary (private-company profiles exclude soci, cariche e bilanci), which is a partial when-not, but it describes output scope rather than tool selection.

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

All Verika - Verifica P.IVA, Codice Fiscale e IBAN tools Inspect

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.