Skip to main content
Glama

Synthex Forge — x402 Paid Agent Services

Get Signed Research Brief

get_signed_research_brief
Read-onlyIdempotent

Signed Research. use it rather than create_signed_research_brief for signed research brief specifically; an object with 7 fields including attestation, disclaimer. $0.5 USDC.

Input Schema

NameRequiredDescriptionDefault
topicNoThe topic the operation concerns.

Output Schema

NameRequiredDescriptionDefault
topicNoThe `topic` field of the response.
summaryNoOne-line summary of the answer.
researchNoThe `research` field of the response.
sha256_ofNoThe `sha256_of` field of the response.
disclaimerNoThe `disclaimer` field of the response.
attestationNoThe `attestation` field of the response.
generatedAtNoThe `generatedAt` field of the response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedOutput schema / properties / attestation
      Added value: +{
      +  "description": "The `attestation` field of the response.",
      +  "type": "object"
      +}
    • addedOutput schema / properties / disclaimer
      Added value: +{
      +  "description": "The `disclaimer` field of the response.",
      +  "type": "object"
      +}
    • addedOutput schema / properties / generatedAt
      Added value: +{
      +  "description": "The `generatedAt` field of the response.",
      +  "type": "object"
      +}
    • addedOutput schema / properties / research
      Added value: +{
      +  "description": "The `research` field of the response.",
      +  "type": "object"
      +}
    • addedOutput schema / properties / sha256_of
      Added value: +{
      +  "description": "The `sha256_of` field of the response.",
      +  "type": "object"
      +}
    • removedOutput schema / properties / status
      Removed value: -{
      -  "type": "string"
      -}
    • addedOutput schema / properties / summary
      Added value: +{
      +  "description": "One-line summary of the answer.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / topic
      Added value: +{
      +  "description": "The `topic` field of the response.",
      +  "type": "object"
      +}
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds valuable context beyond that: it specifies a cost of $0.5 USDC and that the return is an object with 7 fields including attestation and disclaimer.

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?

The text is short but telegraphic: the opening 'Signed Research.' is a wasted fragment, and the second sentence is a semicolon run-on. It does front-load the sibling alternative, but the structure is not polished.

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?

Given a simple getter with rich annotations and an output schema, the description provides enough context: cost and a preview of return fields. The only gap is the meaning of the input topic, which the schema already covers.

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 single 'topic' parameter is fully documented in the schema. The description does not add any meaning about the parameter beyond that, making the baseline 3 appropriate.

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

Purpose4/5

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

The description identifies the resource ('signed research brief') and explicitly contrasts it with the creation sibling, so an agent can tell it is the retrieval counterpart. However, the opening 'Signed Research.' is a fragment that never states a verb like 'get' or 'fetch', leaving the action implicit rather than explicit.

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

Usage Guidelines4/5

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

It directly says to use this tool 'rather than `create_signed_research_brief`' for signed research briefs, giving a clear alternative and selection condition. It doesn't cover when-not to use it beyond that single comparison, but the key routing decision is explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.