Peru Data MCP by Vira

Preview a Peruvian invoice (Facturin)

facturin_preview_invoice

Build a free preview of a Peruvian electronic invoice with IGV (18% VAT) correctly calculated. Nothing is sent to SUNAT; this is a draft to show the user what the document will contain.

`items`: list of {"description": str, "quantity": number, "unit_price": number}.
`document_type`: "boleta" (receipt for consumers) or "factura" (invoice for companies; requires `customer_ruc`).
`prices_include_igv`: true if unit prices already include IGV (usual for boletas). `currency`: "PEN" or "USD".
To issue it for real, valid before SUNAT with PDF, XML and CDR, the user creates a Facturin account.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "facturin_preview_invoice"
  }
}

Input Schema

Name	Required	Default
`items`	Yes
`currency`	No	PEN
`customer_ruc`	No
`document_type`	No	boleta
`prices_include_igv`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses that the call is free and side-effect-free with respect to SUNAT, that IGV is computed at 18%, and that the result is a draft rather than a fiscal document. It stops short of describing what the preview actually returns (totals breakdown, JSON vs PDF), leaving some behavior opaque.

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

Conciseness4/5

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

Front-loaded with purpose and scope in the first paragraph, then parameter semantics in a scannable backtick-labeled list. Every line is informative; the closing account-upsell sentence is mildly promotional but still functional as guidance for real issuance.

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?

For a 5-parameter, no-annotation, no-output-schema tool, the description covers all parameters and the critical behavioral facts (no SUNAT submission, IGV handling). The one remaining omission is the shape of the returned preview, which nothing else in the definition documents.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate and it does: it spells out the item object shape (description, quantity, unit_price), the two valid document_type values with the conditional customer_ruc requirement for factura, the semantics of prices_include_igv, and the PEN/USD currency options. This supplies the enum-like constraints the schema entirely lacks.

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

Purpose5/5

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

States a specific verb and resource ('Build a free preview of a Peruvian electronic invoice') plus the key computation (IGV 18%) and the non-committal scope ('Nothing is sent to SUNAT'). No sibling tool does invoicing, so it is trivially distinguishable from the lookup/trade/pricing tools.

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

Usage Guidelines4/5

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

Clearly frames when to use it (a draft to show the user what the document will contain) and when not to rely on it (it is not valid before SUNAT and has no PDF/XML/CDR), pointing to account creation for real issuance. It gives no in-family alternative, but none of the siblings is a substitute, so that gap is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Peru Data MCP by Vira tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?