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
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
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; get_trust_score, sanctions_preview and wallet_sanctions_preview are free; verify_wallet costs $0.11; 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
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
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
Pay inside A2A with x402 (no API key)
An agent without a Limitguard key can pay per call inside the A2A conversation itself, with the a2a-x402 extension v0.2. The Agent Card declares it undercapabilities.extensions (not required: an API key still works).
- Ask. Send
message/sendtohttps://api.limitguard.ai/a2awith the headerX-A2A-Extensions: https://github.com/google-agentic-commerce/a2a-x402/blob/main/spec/v0.2and a data part{"skill": "verify_wallet", "input": {...}}. For a priced skill you get a Task in stateinput-requiredwhose status message carriesx402.payment.status: "payment-required"andx402.payment.required(the price, the USDC asset and the recipient, on Base and Solana). - Pay. Sign one of those requirements and send
message/sendagain with the sametaskIdand the metadatax402.payment.status: "payment-submitted"andx402.payment.payload(the signed payment). - Result. The payment is checked against the quote issued for that task, the skill runs, and the payment is settled only if the skill succeeded. The completed Task carries the result as an artifact and
x402.payment.receipts. A task can be paid once.
wallet_sanctions (a yes or no against the OFAC list for a wallet, with a daily limit), need no key and no payment. A working Python client that asks for a quote, shows it and asks before signing is in the public limitguard-mcp repository: examples/a2a_x402_pay.py.
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
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 theX-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.
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
Cross-Sell Recommendations
Agents calling one endpoint can discover complementary services at runtime:Response
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 freelg_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 forfresh 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’smaxTimeoutSeconds (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, aspayTo. 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