Skip to main content
Glama
Fatture in Cloud MCP Server

Fatture in Cloud MCP Server

get_archive_document

Read-only

Retrieve full details of an archived document by its ID, optionally scoped to a company, to inspect stored invoice records.

Instructions

Dettaglio completo di un documento d'archivio.

Input Schema

NameRequiredDescriptionDefault
idYes
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

C2.4/5.0
Behavior2/5

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

readOnlyHint=true already tells the agent this is a safe read, and the description only adds the vague qualifier "completo", which hints the payload is fuller than a list entry but doesn't say what fields or related data come back. No mention of error behavior for a missing id or of cross-company access implications.

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

Conciseness3/5

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

It is a single short sentence with no padding, but brevity here comes at the cost of substance rather than from disciplined editing. There is no structure beyond one noun phrase.

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

Completeness2/5

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

With no output schema, an undocumented id parameter, and no annotations beyond readOnlyHint, the description should explain what a "complete detail" includes and how the id is sourced. For a 2-parameter retrieval tool it leaves too much to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: company_id is documented in the schema, but id carries no description. The description does not explain that id refers to an archive document identifier or that company_id resolves to a default company, so it fails to compensate for the gap.

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

Purpose3/5

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

The phrase "Dettaglio completo di un documento d'archivio" does convey retrieving a single archive document in full, which implicitly contrasts with list_archive_documents. However, it never uses a retrieval verb and never names the sibling or the required identifier, so the agent must infer that this is the get-one counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of alternatives such as list_archive_documents, and no stated prerequisite for obtaining the id. The agent gets no routing logic beyond the name.

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