obyte-mcp

Overview Schema Source Related Servers Discussions Admin

Get AA Response Chain

obyte_get_aa_response_chain

Read-onlyIdempotent

Get the complete autonomous-agent response chain for a trigger unit, tracing how Obyte AAs reacted. Choose mainnet or testnet.

Instructions

Raw hub read. Returns the autonomous-agent response chain for a trigger unit.

Network: this server serves both Obyte networks at once. Pass "network":"mainnet" or "network":"testnet" to choose; when omitted it defaults to mainnet. If the user has not made the network explicit, confirm which network they mean before calling.

Amounts: raw ledger amounts in this output are integers in the asset's smallest units (base is GBYTE with 9 decimals). Never show raw integers to users: prefer display_total fields when present, otherwise resolve decimals with obyte_resolve_asset or obyte_get_decimals_by_symbol_or_asset and divide by 10^decimals.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "trigger_unit": "<trigger_unit>"
    },
    "name": "obyte_get_aa_response_chain"
  }
}

Input Schema

Name	Required	Description	Default
`network`	No
`trigger_unit`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Aug 30, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context beyond that: it reveals that the server serves both Obyte networks at once, what the default network is, and that raw amounts are integers in smallest units with explicit instructions for how to display them. This goes well beyond what annotations provide.

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

Conciseness5/5

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

The description opens with a one-sentence purpose, then uses two clearly labeled paragraphs for network and amount handling. Every sentence carries operational weight, and the headings make it easy to scan. No redundant filler.

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?

Because there is no output schema, the description must convey return-value meaning. It says the tool returns the response chain and describes the amount fields (display_total, raw integers), which is helpful. It could still clarify what a 'response chain' contains, but the essential calling requirements—trigger_unit, network selection, and amount interpretation—are covered.

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 0%, so the description must compensate. It explains the network parameter thoroughly, including enum values, the default, and the confirmation rule. However, trigger_unit is only described as 'a trigger unit' with no extra semantic detail such as what kind of unit, how it is used, or expected format beyond the schema constraints. Partial compensation.

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 states a specific verb ('Returns'), a specific resource ('autonomous-agent response chain'), and the key input ('trigger unit'). The phrase 'Raw hub read' signals a low-level read operation, which helps distinguish it from more analytical tools, though it never explicitly contrasts it with the sibling obyte_get_aa_responses.

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

Usage Guidelines3/5

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

The description gives clear network-selection guidance: it explains that both networks are served, that mainnet is the default, and that the agent should confirm the network with the user if not explicitly stated. However, it does not say when to use this tool versus alternatives like obyte_get_aa_responses or obyte_dry_run_aa, so tool-selection guidance is only implied.

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