Rank tenders and projects; compare markets and official evidence for 0.01 USDC x402.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 4 tools
describe_intelligence (metadata) and list_intelligence (inventory) are clearly distinct, but query_intelligence and search_intelligence heavily overlap — both involve locating answers on shelves, one by probing a known shelf and one by keyword discovery. An agent could easily pick the wrong one when it just wants to find a relevant answer.
All four tools follow a strict verb_intelligence pattern (describe_, list_, query_, search_), which is predictable and easy to scan. No mixed conventions or camelCase deviations.
Four tools is reasonable for a discovery-and-metadata layer, though it sits near the thin end given the platform also involves publication and payment flows. Each tool does earn a distinct role, so it is not gratuitously padded.
The surface covers discovery (list, search, describe, query) but exposes no publish/create-shelf operation despite advertising 'publication status,' and purchase is only reachable via an external x402 HTTP client. This leaves a notable gap between the read-only discovery layer and the implied authoring/selling lifecycle.
Get a capability's job, work avoided, input/output schema, example, source, freshness and 0.01 USDC x402 price.
| Name | Required | Description | Default |
|---|---|---|---|
| shelf_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose returned content plus a notable behavioral fact: the call carries a 0.01 USDC x402 price. However it says nothing about auth requirements, error behavior, or failure modes when the shelf_id is unknown, so it is only partially complete for an unannotated tool.
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 dense sentence with the action front-loaded and no filler. It is arguably over-compressed, packing seven return fields into a list, but nothing is wasted.
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?
With no output schema, the description usefully enumerates what comes back, and it even flags the x402 price. But for a tool whose only input is an unexplained required id, the missing parameter meaning and the absence of any usage guidance leave real gaps.
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 0% and there is one required parameter (shelf_id) that the description never mentions or explains. The phrase 'a capability's' hints that some identifier is needed, but the agent gets no meaning for shelf_id, its format, or where to obtain it.
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 ('Get') and resource ('a capability's') and enumerates the fields returned (job, work avoided, schemas, example, source, freshness, price). This clearly reads as a single-item detail lookup, which implicitly distinguishes it from the list/query/search siblings, but it never names those siblings or explicitly says it returns one capability.
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 when-to-use guidance, no prerequisites, and no mention of the alternative tools. The agent must infer that this is for fetching full detail on a capability it already has an identifier for, versus using search_intelligence or list_intelligence to find one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all AIP shelves with access and publication status.
| Name | Required | Description | Default |
|---|---|---|---|
| live_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears the full burden of behavioral disclosure. It conveys that the tool lists shelves and includes statuses, but it does not mention read-only behavior, output shape, pagination, or the effect of the live_only parameter.
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, front-loaded sentence with no filler. It is concise, though it omits important parameter guidance, making it slightly underwhelming in terms of overall helpfulness.
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 tool with one parameter, no output schema, and no annotations, the description is incomplete. An agent cannot correctly use the optional parameter or distinguish this tool from its siblings based on the provided information.
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 0%, and the description does not mention the 'live_only' parameter at all. There is no information anywhere explaining what the parameter means or how to use it.
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 clearly identifies the action ('List'), the resource ('AIP shelves'), and the included details ('access and publication status'). It is specific enough to distinguish the broad listing intent from the other intelligence siblings, though it does not explicitly contrast them.
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 guidance about when to use this tool versus describe_intelligence, query_intelligence, or search_intelligence. The verb 'List all' implies an enumeration use case, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe a selected shelf without signing or spending. A match returns the GET URL and 0.01 USDC x402 payment details; buy through that HTTP URL with an independently authorized x402 client. An unavailable answer is free.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| shelf_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well for the cost model: probing is free, requires no signing or spend, a match returns payment details (0.01 USDC x402), and a non-match is free. It does not disclose rate limits, caching, or what a 'shelf' semantically contains, but the payment/auth behavior is unusually well surfaced.
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?
Three tightly packed sentences with no filler, front-loading the core action and the free/no-signing guarantee before the payment details and follow-up path. The dense jargon is efficient, though slightly cryptic on first read.
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-param tool with no annotations and no output schema, the description adequately explains the return contract (URL plus payment details) and the cost/free condition. The gap is the entirely undescribed 'params' object and the opaque 'shelf' concept, which an agent needs in order to call it correctly.
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 0% across 2 parameters, so the description must compensate and largely fails to. 'Selected shelf' weakly implies shelf_id is a shelf identifier, but the 'params' object — the only channel for actual query input, and a nested object — is never explained, leaving its keys and accepted value types undocumented.
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 states a specific verb ('Probe') and resource ('a selected shelf') and clarifies the output is a GET URL plus x402 payment details rather than the answer itself. This distinguishes it from a straightforward read, though it never names or contrasts with siblings like search_intelligence or list_intelligence, so an agent must infer the boundary.
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?
Usage is implied through the probe-then-buy workflow: this is the free preview step, and the actual purchase happens via the returned HTTP URL with an independent x402 client. However, there is no explicit statement of when to choose query_intelligence over the sibling intelligence tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find paid, source-backed AIP answers for an agent's job, such as ranking tenders, comparing property markets or combining fish, river and weather evidence. Distinguishes live supply from demand tests.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| include_experiments | No |
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. It says answers are 'paid' and 'source-backed' and that the tool distinguishes live supply from demand tests, but it does not disclose permission requirements, return behavior, rate limits, or what 'paid' means operationally.
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 two sentences and front-loads the core action. It avoids repetition or filler, though the compactness comes at the cost of clarity rather than being wasteful.
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?
Given two parameters, zero schema description coverage, no annotations, and no output schema, the description is inadequate. It does not compensate for missing parameter semantics or explain how to choose this search tool over its siblings.
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 0%, and the description does not explain either parameter. The required 'query' parameter and optional 'include_experiments' parameter are left entirely to inference; the phrase about supply vs demand tests may hint at experiments but is not explicit parameter guidance.
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 states a verb and resource: 'Find paid, source-backed AIP answers.' However, 'AIP answers' is cryptic, and the examples do not clearly distinguish this tool from siblings like query_intelligence or list_intelligence. The added phrase about live supply vs demand tests is suggestive but not a clear purpose statement.
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 gives examples of jobs the tool supports, which implies context, but does not say when to use this tool instead of query_intelligence, list_intelligence, or describe_intelligence. There are no exclusions, prerequisites, or explicit when-not-to-use guidance.
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.
describe_intelligencelist_intelligencequery_intelligencesearch_intelligencePaid web research, news, prediction-market evidence, company briefs and fact-checks (x402 USDC)
Compare complete supplier quotes with exact totals and shipping. 0.05 USDC on Base via x402.
8.1M+ US gov and science data via x402 USDC. 21 tools, $0.001 sample tier, sanctions, SEC, CVEs.
Ranked economic opportunities, market evidence, experiments, and margin intelligence for AI agents.
Add one secure layer between your agents and this server.
