Skip to main content
Glama

Signed Research

v1_signed_research
Read-onlyIdempotent

Fetch signed research for a specified topic through a paid x402 route, returning results plus on-chain settlement proof.

Instructions

Signed Research

Remote route: GET /v1/signed-research (0.50 USD x402/base/usdc on eip155:8453).

Input Schema

NameRequiredDescriptionDefault
topicNoQuery parameter `topic`.

Output Schema

NameRequiredDescriptionDefault
statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.3/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description's one genuine contribution beyond annotations is the cost model (0.50 USD via x402 on base USDC, eip155:8453), which is materially useful for an agent deciding to call. It omits latency, rate limits, whether the signature is on the response, and any auth/settlement handshake.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the name, but the first line is pure duplication of the title and therefore does not earn its place. The only substantive content is the route/price sentence, which is appropriately terse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be explained. However, for a paid, open-world research endpoint among ~100 siblings, the description leaves the agent unable to predict what a call yields or when it is the right choice — the core job is unfinished.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is nominally 100%, but the only parameter description is the stub 'Query parameter `topic`.' — it adds no semantics (free-text? taxonomy? length limits?). The tool description likewise says nothing about what a topic accepts, so an agent gets no real guidance despite the coverage number.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The body of the description is the title repeated ('Signed Research') plus a transport line (GET /v1/signed-research). Neither states a verb or what the tool actually produces — 'research' what, returning signed what? It does not distinguish this from close siblings like v1_research_attested_brief, v1_bio_research_reviews, or v1_data_signed_snapshot.

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

Usage Guidelines2/5

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

There is no statement of when to call this vs the many research/attest/verify siblings, and no prerequisites beyond the price line. The x402 payment note implies a paid call but gives no guidance on preflight (e.g. v1_quota_preflight, v1_preflight, v1_budget_preflight) before spending.

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

Deploy Server

Other Tools