Restituisce le scadenze fiscali del mese richiesto, aggiornate automaticamente dall'Agenzia delle Entrate ogni 6 ore tramite scraper. Fonte: agenziaentrate.gov.it/scadenzario. NOTA: Questo è un servizio a pagamento ($0.005/chiamata via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| anno | No | Anno (default: anno corrente) | |
| mese | No | Mese (1-12, default: mese corrente) | |
| tipo | No | Filtro per tipo di scadenza (opzionale) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It adds valuable behavioral details: data is scraped from agenziaentrate.gov.it, updated every 6 hours, and the service costs $0.005 per call. These facts inform the agent about freshness and cost, though it does not cover error behavior or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences plus a cost note. Every sentence contributes: function, data source/update frequency, and pricing. It is front-loaded and free of redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three optional parameters and no output schema. The description covers the core function, update mechanism, and cost. It could mention the return structure (e.g., list of entries with date/description), but the absence is not a significant gap for this straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (anno, mese, tipo) documented with defaults or enums. The description adds no extra parameter-level details beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Restituisce le scadenze fiscali del mese richiesto', clearly stating the tool's function as returning fiscal deadlines for a specified month. This distinguishes it from sibling calculation tools (calcola_*) and news tools (novita_fiscali), which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (retrieve monthly fiscal deadlines) but provides no explicit comparison with alternatives like novita_fiscali or risoluzioni_circolari. It does not state when not to use it, leaving the agent to infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific Italian fiscal or administrative calculation (e.g., codice fiscale, crypto tax, IRPEF) or information retrieval task (e.g., ATECO groups, fiscal news, deadlines), and their descriptions precisely define their scope without overlap.
All tool names follow a consistent verb_noun pattern in Italian (e.g., calcola_codice_fiscale, lista_gruppi_ateco, novita_fiscali). The naming is uniform across all tools, using snake_case and descriptive terms that align with their functions, making them easily readable and predictable.
With 9 tools, the count is well-scoped for the server's purpose of providing Italian fiscal and administrative tools. Each tool earns its place by covering key areas such as tax calculations, regulatory information, and deadlines, offering a comprehensive yet manageable set for agents to handle related tasks.
The tool set provides strong coverage for Italian fiscal calculations and information retrieval, including core tax types (e.g., IRPEF, INPS, forfettario), administrative codes, and regulatory updates. Minor gaps might exist, such as tools for specific deductions or advanced tax scenarios, but agents can likely work around these with the available tools for most common workflows.