[GET /v1/pricing — $0.00] Machine-readable price ladder for all endpoints/tools plus the payment flow. Always free.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_token | No | Payment proof: dev mode → single-use token from POST /v1/dev-faucet; x402 mode → base64 payment payload (the PAYMENT-SIGNATURE / X-PAYMENT header value) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds that the tool is always free and that the response is machine-readable, which are useful runtime traits beyond the structured metadata. There is no contradiction with the annotations.
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 a single compact line with the method, cost, and output scope front-loaded. 'Always free' is slightly redundant with '$0.00', but it is still short and reinforces an important calling behavior 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, optional-parameter GET annotated as safe and idempotent, the description provides the essential selection facts: endpoint, scope, output form, and cost. The absence of an output schema is partially mitigated by characterizing the result as a machine-readable price ladder, though exact response structure is not specified.
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 input schema fully documents the optional payment_token, including dev-mode token vs x402 base64 payload, and the description adds no parameter-specific meaning. With 100% schema coverage, the baseline of 3 is appropriate.
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 identifies the operation as GET /v1/pricing and the output as a machine-readable price ladder. It clearly scopes the resource to all endpoints/tools plus the payment flow, which distinguishes it from sibling billing tools such as billing_get_balance and billing_purchase_credits.
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?
It does not explicitly name sibling alternatives or state when to avoid this tool. The phrase 'for all endpoints/tools plus the payment flow' and 'Always free' imply it is the go-to source for price information, but the when/when-not guidance is left mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a distinct resource or action: billing balance, credit purchase, company profile/awards/opportunities, tender search/detail, renewals, buyer history, and research brief. The only possible overlap is research versus raw query tools, but the descriptions clearly separate a high-level brief from raw rows.
Most tools follow a readable get_<resource> pattern, but billing_get_balance, billing_purchase_credits, search_tenders, and research deviate with namespace prefixes, a different verb, and a bare noun. The naming is not chaotic, but the conventions are mixed.
With 11 tools, the server is well-scoped for a procurement-intelligence API: search, detail views, company and buyer analytics, renewal signals, research, pricing, and billing support. Each tool has a clear place and there are no obvious redundant tools.
The tool set covers the full core workflow: search for tenders, get full tender detail, explore company and buyer profiles, retrieve opportunities and renewals, generate research briefs, and manage billing. Ids returned by searh feed into detail tools, and no exposed data type appears to be a dead end.