Skip to main content
AI agents now qualify leads, onboard suppliers and pay invoices with little or no human review. Most have no way to check whether the company on the other side is real, active and not sanctioned. Limitguard gives them the checks a person would run: the company behind a lead or invoice is looked up in the official business register (KVK in the Netherlands, KBO in Belgium), its VAT number in VIES and its name on the OFAC, EU and UN sanctions lists, with the source on every line. It exposes those checks through three agent-native protocols, MCP, A2A and x402, so any capable agent can discover, pay for, and act on them without human configuration.

MCP

Native tools for Claude, GPT-4, and any LLM that supports the Model Context Protocol

A2A

Google’s Agent-to-Agent protocol: structured capability discovery and invocation

x402

Pay per call with USDC. No subscription, no API key, no human in the loop
All discovery endpoints (/.well-known/*, /llms.txt, /llms-full.txt) are free and unauthenticated. An agent can discover Limitguard’s full capabilities without a wallet or API key.

Why Lead and Company Checks Matter for Agents

An autonomous agent qualifying a lead or executing a payment faces a fundamental asymmetry: it can verify its own instructions perfectly, but it has no ground truth about the company on the other side. A lead or supplier claiming to be “Acme Corp BV” in Amsterdam could be:
  • A legitimate, 12-year-old company with verified KVK registration
  • A recently-incorporated shell with no trading history
  • An entity on an OFAC or EU sanctions list
  • A domain registered last week pointing to a known fraud cluster
Without trust verification, agents must either halt for human review (defeating the purpose of automation) or proceed blind (accepting counterparty risk they cannot quantify). Limitguard resolves this in a single API call. Lead Verify returns a verdict, a 0-100 lead score and flags; the company check returns a 0-100 trust score, a recommendation (proceed / review / enhanced_due_diligence / block), and the evidence behind it.

Agent Decision Framework


Protocol Overview


MCP (Model Context Protocol)

MCP is Anthropic’s standard for exposing APIs as native tools to LLM agents. When an LLM is configured with Limitguard’s MCP manifest, it can call Limitguard’s checks the same way it calls any built-in tool, with no prompt engineering required.

Discovery

Response
Trimmed here: the top-level description goes on to the sandbox and prices, and each tool in the live manifest also carries an inputSchema and annotations (title and read-only hints). check_entity and get_risk_score cost the same as the fresh tier of the endpoint they mirror; verify_wallet, get_trust_score and sanctions_preview are free; get_compliance_report, sanctions_screen, check_agent_wallet and verify_lead are billed at the price of the REST endpoint they call. See Pricing for the amounts.

Configuring an LLM Agent

When writing system prompts, instruct the agent explicitly: “Before executing any payment or onboarding a new supplier, always call check_entity. Only proceed if recommendation is proceed or review.” LLMs follow clear tool-use instructions reliably.

A2A (Agent-to-Agent)

Google’s Agent-to-Agent protocol defines a standard for agents to discover and invoke other agents as structured services. Limitguard publishes an Agent Card that exposes its capabilities, skills, and invocation interface to any A2A-compatible agent.

Discovery

Response
Trimmed here: the live card’s description goes on to the sandbox and prices, and the entity_check skill’s description is shortened. Each skill names the REST endpoint and method to call and its price_usdc.

How an Agent Uses A2A


x402 Micropayments

x402 is the HTTP native payment protocol for AI agents. An agent with a funded USDC wallet can call Limitguard endpoints without a subscription or API key: it discovers pricing, builds a cryptographic payment signature, and includes it in the request header. This is the fully autonomous path: no human creates an account, no API key is provisioned, no billing is configured.

Discovery

Response
Truncated to three entries; the live response lists every priced endpoint. price_raw is the default (fresh) price in USDC 6-decimal units. The listing does not break out per-quality-tier prices: for cached amounts, see Pricing or read the amount from the 402 response for the quality you requested.

How x402 Works

1

Probe the endpoint (optional)

Make a request without payment. The server returns HTTP 402 with the exact payment requirements for this call. You can skip this step if you already read requirements from /.well-known/x402.json.
2

Build the payment signature

Construct an EIP-3009 TransferWithAuthorization signature authorizing the USDC transfer. Sign it with your agent’s wallet private key.
3

Base64-encode the payment object

Serialize the payment payload to JSON and base64-encode it. This becomes the X-PAYMENT header value.
4

Retry the request with X-PAYMENT

Send the original request again, including the X-PAYMENT header. Limitguard verifies the signature on-chain, executes the transfer, and returns the trust score.
5

Check response headers

Confirm X-Payment-Verified: true. If you see X-Payment-Fallback: true, the circuit breaker triggered a cached-wallet path (rare).

Full x402 Implementation

Quality Tiers

Control cost vs. freshness with the X-Response-Quality header. The payment amount must match or exceed the tier price. enhanced was retired on these endpoints on 2026-09-24: it ran the same sources as fresh, so it is now quoted, charged and served at the fresh price. For more sources, use POST /v1/entity/deep-check.
For high-frequency screening (e.g., checking every inbound invoice), start with cached for pre-screening and only upgrade to fresh when the cached score is below 70. A cached entity check costs about 9.5x less than a fresh one (see Pricing), which is what this saves on clean counterparties.

End-to-End Agent Example

This example shows a complete autonomous payment agent, from cold start to decision, using discovery, x402 payment, and trust-gated execution.

Complete Implementation


llms.txt: LLM Context Loading

Limitguard implements the llms.txt standard: machine-readable files that let any LLM load a structured API summary into its context window.

Endpoints

When to Use llms.txt

Use /llms.txt (concise) for general-purpose agents where token budget matters. Use /llms-full.txt when the agent needs to generate code that calls Limitguard: the full reference includes request/response schemas and error codes.

Cross-Sell Recommendations

Agents calling one endpoint can discover complementary services at runtime:
Response
The endpoint needs an API key (a free or sandbox key works). An optional trust_score parameter is accepted but does not change the answer today. Agents can use this to self-direct their verification strategy without hardcoded decision trees.

Sandbox Mode for Agent Development

Build and test your agent integration without spending USDC or calling real data sources.

Activating Sandbox for Agents

Sandbox mode is decided by the key: create a free lg_sandbox_ key once and send it like any other key. There is no sandbox header, and lg_test_ keys are refused in production.

Sandbox Behavior Reference

Writing Agent Tests with Sandbox


Best Practices

1. Cache Discovery Responses

Discovery endpoints don’t change between deploys. Cache them aggressively.
The discovery files carry no Cache-Control header, so choose your own refresh interval: an hour is plenty, and refreshing more often adds latency with no benefit.

2. Handle HTTP 402 Gracefully

A well-built agent treats 402 as a normal flow, not an error.

3. Use Quality Tiers Strategically

Don’t pay for fresh when cached is sufficient.

4. Log Trust Scores in Your Audit Trail

For regulated workflows, store the trust score alongside the transaction:

5. Set Nonce Expiry Windows Conservatively

The server remembers each x402 nonce for ten minutes, the quote’s maxTimeoutSeconds (600). Keep validBefore inside that window: now + 300 (five minutes) is tight enough to prevent replay attacks and wide enough to survive network retries.

6. Never Hardcode Facilitator Addresses

The facilitator address is returned dynamically in each 402 response, as payTo. Always read it from the response: never hardcode it. The address can change during upgrades.

Protocol Comparison


Next Steps

x402 Protocol

Full x402 implementation guide with EVM and Solana examples

Discovery

All machine-readable discovery endpoints

Sandbox

Test your agent integration for free

API Reference

Interactive playground for every endpoint