Agent Procurement Manager (APM)

apm_register

Free "membership card": register your agent and get a caller_id. Present that caller_id in future apm_quote / apm_preview calls and APM recognizes you, remembers which categories you asked about and what you were quoted (category + price only — never your task inputs), and greets you with a since-you-last-asked note. No wallet and no payment needed. One card per agent: re-registering with the same name updates your existing card instead of issuing a new one. This tool is free and never executes a purchase. To execute: take the quote_id from apm_quote (or POST /quote), then call POST /task?quote=<quote_id> and pay customer_price in USDC on Base (eip155:8453) via x402. Questions, bulk needs, or a category you cannot find: the operator (a human) is on Telegram @realDMT.

Input Schema

Name	Required	Description
`name`	No	What to call your agent
`contact`	No	Optional: how the operator can reach you or your operator
`endpoint`	No	Optional: your own service endpoint (MCP or API URL), if you run one — our operator may visit it (read-only) to understand what you do
`looking_for`	No	What you shop for (categories, data types, volume) — helps APM stock what you need
`referred_by`	No	Optional: who sent you — another agent's caller_id or name; referrals get counted

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 20, 2026

addedInput schema / properties / endpoint

Added value: +{
+  "description": "Optional: your own service endpoint (MCP or API URL), if you run one — our operator may visit it (read-only) to understand what you do",
+  "type": "string"
+}

addedInput schema / properties / referred_by

Added value: +{
+  "description": "Optional: who sent you — another agent's caller_id or name; referrals get counted",
+  "type": "string"
+}

AddedOct 20, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full load and does so well: it discloses cost (free), that no wallet/payment is needed, that it never executes a purchase, the data-retention policy (category+price only, never task inputs), the idempotent upsert behavior on re-registration, and a human escalation path on Telegram.

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?

Core purpose is front-loaded and each early sentence earns its place. However, the paragraph describing how to execute a purchase via apm_quote/POST /task is a different tool's workflow, and the trailing Telegram/operator sentence adds promotional weight beyond what this tool strictly needs.

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?

No output schema or annotations exist, but the description compensates by explaining what you receive (a caller_id) and the greeting/recall behavior. It stops short of describing failure modes (e.g., duplicate-name edge cases or invalid inputs), which would round out a zero-required-param registration tool.

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 the schema already documents all five parameters and the baseline is 3. The description adds genuine semantic nuance for one parameter ('re-registering with the same name updates your existing card'), but nothing extra for contact, endpoint, looking_for, or referred_by.

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 ('register your agent and get a caller_id') and immediately frames the output artifact (caller_id) that other tools consume. It cleanly distinguishes itself from apm_quote/apm_preview by naming them as downstream consumers.

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

Usage Guidelines5/5

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

Explicitly says to present the caller_id in future apm_quote / apm_preview calls, clarifies re-registration semantics (same name updates the card), and routes purchase execution elsewhere (quote_id → POST /task). Both the 'when to use' and the 'this is not for buying' boundary are stated.

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

All Agent Procurement Manager (APM) 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?