Retrieve a company's tax profile in Fatture in Cloud to view its registered regime, coefficient, rate, and social security data for tax estimates.
Profilo fiscale usato per stimare le tasse (coefficiente, aliquota, previdenza) e regime registrato in Fatture in Cloud.
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | No | Azienda su cui operare. Default: FIC_COMPANY_ID o l'unica azienda del token |
Changes observed during successful MCP inspections.
v0.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds the useful content hint that the profile comprises coefficient, rate, previdenza and the registered regime, but discloses nothing about whether the profile is company-scoped, what happens when no profile is configured, or what the read returns beyond those field names.
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?
A single compact sentence with no filler, and the parenthetical field list is informative rather than redundant. Its front-loading is weakened only by leading with a noun phrase instead of the retrieval action.
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 one-parameter read tool with readOnlyHint and no output schema, the definition is minimally adequate: it tells the agent what concepts the profile contains. However, it never states that the call retrieves the currently configured profile for a company (or that other tools consume these values), leaving a real gap that the schema's default-value note only partially fills.
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?
With a single parameter and 100% schema description coverage, the schema already explains company_id and its default fallback to FIC_COMPANY_ID / the token's sole company. The description adds no meaning about company scope or what changing it implies, so baseline 3 applies.
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 names the resource domain (tax profile: coefficient, rate, social security, registered regime in Fatture in Cloud) but never states the action — it is a noun-phrase definition rather than 'retrieves the company's tax profile'. An agent must infer from the tool name 'tax_profile_get' and the sibling 'tax_profile_set' that this is a read of the configured profile, not an estimate calculation.
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?
There is no when-to-use guidance and no routing to alternatives, even though close siblings exist (tax_estimate, regime_simulator, tax_profile_set). Nothing tells the agent whether to call this before estimating taxes or how it differs from those tools; usage is only implied by the shared 'tax' prefix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.