Afriref: cited government reference data

invoice_payable

Read-onlyIdempotent

PAID ($0.40). Is this invoice overdue, by how many days, and how much statutory late-payment interest is owed (Actual/365 simple, rate and workings cited). Late-payment regime: none here; statutory interest only: BF, BJ, BW, CI, CM, DZ, EG, ET, MA, ML, MU, MZ, NA, NE, SN, TG, TN, ZA. Send due_date, or invoice_date with terms_days. Anything we cannot answer in full is refused free (coverage_gap, no_charge). Shares the 3 free calls per IP per day with the answer tools. Pass api_key if you have one (card checkout at /pricing); otherwise the result is the x402 payment requirement. Optional receipt (boolean, default false): on a paid success, include an Ed25519 answer receipt at no extra USDC. An answer receipt is not a series certified extract (GET /v1/certified/{country}/{series} is $0.10 and is not an MCP tool) and is not legal advice. Verify with verify_answer_receipt against /certified/public-key.

Input Schema

Name	Required	Description
`as_of`	No	YYYY-MM-DD payment date or day asked about; default today
`debtor`	No	Default business
`api_key`	No	API key (bypasses x402; metered for invoicing)
`country`	Yes	ISO country code
`receipt`	No	Default false. When true, a paid success includes an Ed25519 answer receipt (kind answer_receipt) at no extra USDC. Unpaid 402 and free refusals do not include one. Not a series certified extract (GET /v1/certified/{country}/{series} at $0.10; that SKU is not an MCP tool).
`due_date`	No	YYYY-MM-DD contractual due date
`principal`	Yes	Unpaid amount, local currency
`terms_days`	No	Agreed payment term in days
`invoice_date`	No	YYYY-MM-DD; with terms_days instead of due_date

Output Schema

Name	Required	Description
`job`	No
`error`	No	Present on a free refusal or error; no charge
`status`	No
`evidence`	No
`no_charge`	No
`price_usd`	No
`disclaimer`	No
`how_to_pay`	No
`bind_series`	No
`explanation`	No
`x_next_bind`	No
`http_endpoint`	No
`payment_required`	No	true when the call needs payment; how_to_pay explains x402 or card

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 19, 2026

TDQS

A3.7/5.0

Behavior5/5

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

Annotations only cover read-only/open-world/idempotent safety. The description adds payment requirement ($0.40/x402), shared free-call limits, no_charge refusal behavior, receipt issuance details, legal disclaimer, and verification path, which is rich context beyond structured fields.

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

Conciseness2/5

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

It front-loads the purpose, but the wall of sentences mixes pricing, free calls, receipt mechanics, legal disclaimers, and verification. The 'PAID ($0.40).' opening and overall length are noisy rather than concise.

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?

An output schema exists, so return details need not be repeated. The description covers inputs, country coverage, refusal semantics, payment model, and receipt behavior, making it nearly complete for a paid read-only computation tool, though not elegantly organized.

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 description coverage is 100%, so baseline is 3. The description restates the due_date vs invoice_date+terms_days alternative and the country list, but adds little syntax or format detail beyond what the schema already provides.

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?

The question-form first sentence names the computation: invoice overdue status/days and statutory late-payment interest, with covered countries listed. It distinguishes from certified extracts and legal advice, but does not explicitly contrast with sibling compute_statutory_interest.

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?

Provides an input recipe (due_date or invoice_date with terms_days) and payment/free-call constraints, plus refusal behavior. It does not state when to choose this tool over compute_statutory_interest or other interest siblings.

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

All Afriref: cited government reference data 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?