Skip to main content
Glama
Fatture in Cloud MCP Server

Fatture in Cloud MCP Server

revenue_summary

Read-only

Summarizes annual revenue and collected amounts by month and client, and tracks forfettario progress toward the €85,000 threshold with year-end projection.

Instructions

Fatturato e incassato dell'anno, per mese e per cliente. Per il regime forfettario mostra quanto manca alla soglia di 85.000 € (principio di cassa) e la proiezione a fine anno.

Input Schema

NameRequiredDescriptionDefault
yearNoDefault: anno corrente
limitNoSoglia, default 85000
company_idNoAzienda su cui operare. Default: FIC_COMPANY_ID o l'unica azienda del token

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.6/5.0
Behavior3/5

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

readOnlyHint=true already establishes the safety profile, so the description adds the meaningful part: the threshold check is computed on a cash basis (principio di cassa) and includes a year-end projection. It does not describe the response shape or breakdown granularity limits, but for a read-only report this is adequate context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler; the primary content (revenue/cash-in by month and client) is stated first and the regime-specific threshold behaviour second. Every clause carries information.

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

Completeness4/5

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

With no output schema, the description does the work of explaining the returned content: monthly and per-client figures, threshold gap, and projection. Only minor gaps remain, such as whether amounts are net of VAT or which currency/rounding applies.

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%, with the schema already documenting year (default current year), limit (default 85000) and company_id defaults, so the baseline is 3. The description adds meaning by tying the 85.000 € value to the forfettario regime, clarifying what `limit` actually represents, but nothing beyond that.

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 concretely what the tool returns: annual revenue and cash collected, broken down by month and by client, plus flat-rate-regime threshold progress and year-end projection. A specific resource and breakdown are named, though no sibling tool (receivables_report, receipts_monthly_totals, cashflow_forecast) is referenced to disambiguate.

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 by the content ('fatturato e incassato dell'anno'), so an agent can infer this is the annual revenue overview. However, there is no explicit when-to-use, no exclusions, and no routing away from the many overlapping report siblings such as receivables_report or cashflow_forecast.

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