Skip to main content
Glama
Sign In
Portale Offerte MCP

Portale Offerte MCP

by marcopa84
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

cerca_offerte

Read-only

Search and filter Italian electricity and gas offers by area, seller, price type, and consumption to compare estimated annual costs and identify suitable options.

Instructions

Cerca offerte luce e gas del Portale Offerte filtrando per tipo, zona, venditore e prezzo.

Con consumo_annuo le offerte sono ordinate per costo annuo stimato della sola parte vendita
(esclusi rete, oneri, imposte): utile per confrontare, non e la bolletta.

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": {
      "commodity": "<commodity>"
    },
    "name": "cerca_offerte"
  }
}

Input Schema

NameRequiredDescriptionDefault
fonteNoSolo mercato libero o solo offerte PLACET
saltaNoRisultati da saltare (paginazione)
testoNoTesto da cercare nel nome o nella descrizione dell'offerta
comuneNoComune di fornitura: nome, 'Nome (SIGLA)' o codice ISTAT a 6 cifre
limiteNo
regioneNoRegione (nome), in alternativa al comune
commodityYesluce, gas o dual (luce+gas)
residenteNoSolo per domestici: cliente residente o no
venditoreNoParte del nome del venditore o partita IVA
ordina_perNoOrdinamento; predefinito costo_stimato se c'e il consumo, altrimenti venditore
potenza_kwNoPotenza impegnata in kW (luce)
tipo_prezzoNoPrezzo fisso, variabile (indicizzato), flat o misto
tipo_clienteNoTipo di clientedomestico
consumo_annuoNoConsumo annuo (kWh per la luce, Smc per il gas). Se indicato, esclude le offerte fuori dai limiti di consumo e ordina per costo stimato
raggruppa_versioniNoMostra una sola riga per le versioni della stessa offerta (stesso venditore e nome, es. edizioni mensili); le altre sono in altre_versioni
riferimento_indiciNoValore degli indici per le stime delle offerte variabiliultimo_mese
includi_non_ancora_valideNoIncludere anche offerte con validita futura o scaduta

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover read-only and open-world, and the description adds a genuinely useful caveat the annotations cannot: that the ranking figure is the vendita component only, excluding rete, oneri and imposte, so it is comparable but not a bill. It does not describe the result envelope, pagination behavior, or what raggruppa_versioni does to the payload, which keeps it short of a 5.

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?

Two sentences, front-loaded with the verb and scope, with the cost caveat packed into a tight clause. The stray line break and the em-dash aside add minor noise but nothing is padded or repetitive enough to cut.

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

Completeness3/5

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

For a 17-parameter tool with no output schema, the description covers purpose and the cost-ranking caveat but says nothing about what a result row contains, how salta/limite pagination interacts with raggruppa_versioni, or that other versions land in a separate field. The rich schema carries most of the burden, but the return-shape gap is real given there is no output schema.

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 94%, so nearly every parameter is already self-documenting and the baseline is 3. The description restates the consumo_annuo-ordering relationship already present in that parameter's schema text rather than adding new meaning (e.g., valid ranges, interaction between comune and regione, or units for potenza_kw).

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

Purpose4/5

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

States a specific verb and resource ('cerca offerte luce e gas del Portale Offerte') plus the filter axes (tipo, zona, venditore, prezzo), so an agent immediately knows this is a search/list tool over the Portale Offerte catalog. It implicitly separates itself from dettaglio_offerta and stima_costo by being the discovery step, but never names a sibling explicitly.

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?

The second sentence gives real guidance on when the ordering/cost semantics apply (when consumo_annuo is provided) and warns the cost is not the bill. However it never states when to prefer this tool over dettaglio_offerta (to inspect one offer) or stima_costo (to price a specific offer), so the routing decision is left to inference.

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

Deploy Server

Other Tools