Provides crypto quotes and market data from CoinMarketCap through APM's crypto_market category, purchasable via the x402 flow.
A procurement agent for AI agents. Your agent describes a data task, APM gets quotes from verified suppliers, buys the best one with its own float, checks the result, and delivers it in a standard format. Payment is per task in USDC on Base via the x402 protocol — no accounts, no API keys, no subscriptions.
Live service: https://humming-moonstone-galleria.ngrok-free.dev
Free MCP endpoint: POST /mcp on the live service (tools: apm_quote, apm_preview, apm_categories)
Free preview (no payment, no execution): POST /preview
Free quote: POST /quote
Listed on the official MCP Registry as io.github.lgs1520/agent-procurement-manager
Registered on-chain in the ERC-8004 Identity Registry (Base, agentId 222182)
Also available on Virtuals ACP and Agentverse (@apm-storefront)
APM resells verified data services from 60 suppliers across 7 categories, discovered from the live x402/CDP Bazaar catalogue and admitted only after a live probe confirms they charge exactly their catalogue price in Base-mainnet USDC.
Category | Examples of tasks | Typical customer price |
| Token contract safety summary (honeypot, taxes, mint/freeze powers, holder risk) | $0.011–$0.021 |
| Wallet activity summary for an EVM address | $0.011–$0.021 |
| Web search results with titles, URLs and snippets | $0.011–$0.021 |
| People/company enrichment and search (premium suppliers) | up to $0.561 |
| Market and price data | ≤ $0.05 |
| Crypto quotes and market data (incl. CoinMarketCap) | ≤ $0.05 |
| Social/Twitter search and data | ≤ $0.05 |
| One order = best of token_risk + wallet_onchain + web_search | $0.029 |
Pricing rule (never at a loss, always disclosed in the quote): max(supplier cost × 2, cost + $0.005 margin + $0.001 compute), rounded up to $0.001. Per-order cap $0.05 (data_enrichment: $0.30). If a supplier result fails validation, the order is marked refund_pending instead of delivering unreliable data.
Related MCP server: Agentic Swarm Marketplace
POST /quote with {"task": "<category>", "input": "<address | contract | query>"} → returns a quote with the customer price and the selected supplier.
POST /task?quote=<quote_id> with an x402 payment header (Base mainnet USDC, EIP-3009) at exactly the quoted price.
APM executes the purchase from the best supplier, validates the result, and returns {result, supplier, supplier_cost, customer_price, confidence, order_id}.
Not sure yet? POST /preview with the same body returns the top-3 supplier comparison and the price without executing or charging anything (rate-limited free taster).
Remote (zero install): point your MCP client at the hosted endpoint:
{
"mcpServers": {
"apm": { "url": "https://humming-moonstone-galleria.ngrok-free.dev/mcp" }
}
}Local stdio bridge (this repo): a small open-source bridge that exposes the same three free tools and forwards them to the live APM API:
npm install
npm start # stdio MCP server: apm_quote, apm_preview, apm_categoriesSet APM_BASE_URL to override the APM endpoint. The bridge never handles payments — ordering happens through the x402 flow above.
How does an AI agent pay for data without a credit card?
Through APM: the agent holds USDC on Base and pays per task via x402 (HTTP 402 + EIP-3009 signed transfer). APM's free /quote and /preview endpoints let the agent check the exact price before committing funds.
What is the cheapest way to get a token risk summary via API?
APM's token_risk category starts at $0.011 per summary, aggregated from multiple verified suppliers; /preview shows the live comparison before you buy.
Can an agent buy web search results with USDC?
Yes — the web_search category returns structured results (title, URL, snippet) for a query, priced per call, payable in Base USDC via x402.
What happens if a supplier returns bad data?
APM validates results. Unreliable results are not delivered as facts; the order is recorded as refund_pending and the failure counts against the supplier (3 consecutive failures auto-pause a supplier).
This repository contains the public documentation and the open-source MCP bridge. The procurement engine itself runs as a hosted service at the live endpoint above. Supplier admission rule: a supplier is listed only if one of its x402 payment options is Base-mainnet USDC at exactly its catalogue price, verified by a live probe.
License: MIT for the bridge code in this repo.
List the categories and verified suppliers currently available through Agent Procurement Manager.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. Beyond the word "List" (implying a read) and "currently available" (implying live, non-cached data), it says nothing about permissions, pagination, result size, or refresh behavior. For a zero-annotation tool this leaves meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or redundancy. It is appropriately sized, though the brevity contributes to the gaps noted elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument discovery tool this is minimally adequate, but with no output schema and no annotations the description could reasonably state what a "category" or "verified supplier" record contains and how results are shaped. Those details are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ("List") with specific resources ("categories and verified suppliers") scoped to Agent Procurement Manager. It is clear what the tool returns, but it does not contrast itself with the siblings apm_quote or apm_preview, so an agent must infer that this is the discovery/browse step of that trio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use statement, no prerequisite, and no mention of the alternatives apm_quote and apm_preview. An agent can only guess that this is the browsing entry point before quoting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free taster: compare the top-3 suppliers APM would buy from for a task, with the customer price. No execution, no payment.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task category, e.g. web_search | |
| input | Yes | Contract address, wallet address, or search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the key behavioral trait — no execution, no payment, i.e. side-effect-free — which is genuinely useful. But it omits auth requirements, rate limits, and whether the preview is cached or live, so behavioral coverage is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the value proposition front-loaded ('Free taster') and the safety guarantee trailing. Every clause earns its place, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-required-param tool with no output schema, the description tells the agent what comes back (top-3 suppliers plus customer price) and that nothing executes. That covers the essential loop; only edge cases like invalid task categories are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'task' and 'input' are already documented in the schema. The description only echoes that a task is involved and adds no format, example, or constraint beyond what the schema provides, which is the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (compare top-3 suppliers APM would buy from) with a clear output (customer price) and scoping caveat (free taster, no execution). It is distinguishable from apm_quote by the preview/no-execution framing, though it never names the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free taster' plus 'no execution, no payment' implies this is a dry-run to try before committing, which is usable guidance. However, it never says when to prefer this over apm_quote or what the preconditions are, leaving the agent to infer the sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a free price quote from Agent Procurement Manager for a data task (categories: token_risk, wallet_onchain, web_search, data_enrichment, market_data, crypto_market, social_data, due_diligence). No charge, no execution.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task category, e.g. token_risk | |
| input | Yes | Contract address, wallet address, or search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It usefully states that the quote is free and does not execute anything, covering cost and side-effect behavior. It does not describe authentication needs, rate limits, or what the returned quote includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and is only one sentence. The parenthetical category list is dense but necessary for parameter meaning. It is appropriately sized with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter quote tool, the description covers purpose, cost, and non-execution. Because there is no output schema, it should ideally explain what a quote response contains or how the task categories relate to input formats; those gaps leave it merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds meaningful value by enumerating all eight task categories, while the schema only gives token_risk as an example. It still does not map each category to the expected input type, so it falls short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: "Get a free price quote from Agent Procurement Manager for a data task." The category list further scopes the purpose. It does not explicitly distinguish this tool from siblings apm_preview or apm_categories, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrases "No charge, no execution" imply this is for quoting rather than performing work, and the category list suggests valid task types. However, there is no explicit guidance on when to use this versus apm_preview or apm_categories, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0apm_categoriesapm_previewapm_quoteScored across 3 tools
apm_quote and apm_preview both return free pricing information with no execution or payment, making their boundary somewhat fuzzy—one is a single price, the other a top-3 supplier comparison. Descriptions do clarify the distinction, but an agent must read carefully to pick correctly. apm_categories is clearly distinct.
All three tools share the apm_ prefix followed by a single descriptive noun/verb (quote, preview, categories), giving a predictable and readable pattern. Minor deviation in that 'quote' and 'preview' are verbs/nouns of different types, but overall consistent.
Three tools is thin for a procurement domain and feels borderline—especially since the surface stops at quoting and never reaches actual purchasing. The low count is coherent with a quote-only gateway, but leaves it feeling underbuilt.
The tool set is a dead end: it can quote prices, compare suppliers, and list categories, but there is no way to actually place an order or execute a purchase, nor check order status. For an 'agent procurement manager' the core transaction lifecycle is entirely missing.
Remote MCP storefront for agent routing, verification, web extraction and x402-paid tools.
Remote MCP utilities for agents: structured data, commerce checks, and x402 paid API discovery.
x402 endpoint and MCP server index: find paid APIs for agents, x402 checks and price benchmarks.
Remote MCP server exposing 330 production AI-agent services for web/data processing, validation, AI utilities, blockchain/crypto utilities, and x402 pay-per-use access.
