Restituisce le ultime notizie e novità fiscali da FiscoOggi.it, aggiornate ogni settimana tramite scraper RSS. NOTA: Questo è un servizio a pagamento ($0.005/chiamata via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Numero massimo di articoli da restituire (1-50, default: 10) | |
| categoria | No | Filtro per categoria (es: prassi, novità, comunicato — opzionale) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond a bare function: it specifies the source (FiscoOggi.it), update cadence (weekly via RSS scraper), and a cost note ('$0.005/chiamata via x402'). However, it does not disclose return format, pagination, or any error behavior. With no annotations provided, the description carries the burden but only partially fulfills it.
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 a single concise sentence followed by a brief cost note. It front-loads the main purpose and includes only essential information. No superfluous words, making it highly efficient.
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?
For a simple two-param tool with no output schema, the description covers key aspects: source, update frequency, cost, and purpose. However, without an output schema, it does not specify the structure of the returned news items (titles, links, dates, etc.), which leaves some ambiguity. Adequate but with room for improvement.
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% for both 'limit' and 'categoria', and their descriptions are clear. The tool description adds no further semantic detail about the parameters, so it relies entirely on the schema. Baseline of 3 is appropriate since the schema fully documents the parameters.
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 clearly states the tool's function: 'Restituisce le ultime notizie e novità fiscali da FiscoOggi.it' (returns latest tax news from a specific source). It identifies a specific verb ('restituisce'), resource ('notizie fiscali'), and source ('FiscoOggi.it'), effectively distinguishing it from sibling tools like calcola_codice_fiscale and risoluzioni_circolari.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention cases like needing official resolutions (where risoluzioni_circolari might be more appropriate) or when not to use it. The only contextual hint is the 'aggiornate ogni settimana' note, but there is no explicit comparison to siblings.
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.