obyte-mcp

by Taump

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
Disambiguation3/5
The tools are grouped into raw hub reads, recommended analyze helpers, and registry resolvers, which mostly helps. However, obyte_prepare_aa_dry_run and obyte_dry_run_aa are described almost identically, and obyte_resolve_asset largely overlaps with the granular symbol/asset/decimals lookup tools.
Naming Consistency4/5
The obyte_ prefix and snake_case verb_noun pattern are consistent and readable. Minor deviations like obyte_prepare_aa_dry_run vs obyte_dry_run_aa and the awkward obyte_get_aas_by_base_aas keep it from being perfect.
Tool Count2/5
30 tools is beyond the well-scoped range and the surface feels inflated by redundant families: the dry-run pair, the multi-tool resolver set, and analyze wrappers sitting alongside raw getters. Consolidation would make this a tighter, more navigable server.
Completeness4/5
The server covers the read/analysis domain well: addresses, units, AA state and responses, assets, holders, attestations, and network diagnostics are all represented. It lacks transaction broadcast/signing tools, but the server appears intentionally scoped to read-only and dry-run operations.
Average 4.3/5 across 30 of 30 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive; the description adds the 'Raw hub read' characterization and the network-default/confirmation requirement. This is useful but does not disclose error behavior or the exact structure of the returned result. With annotations covering the safety profile, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and then the network note. Every sentence earns its place; the network paragraph is necessary given the dual-network setup. No redundancy or fluff.
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?
For a 4-parameter tool with no output schema, the description covers the main purpose, the optional args, and the critical network-confirmation protocol. It does not specify the return format, but 'returns the getter result' is adequate. The description is sufficient for an agent to call the tool correctly, assuming network ambiguity is resolved.
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 that args are optional JSON and that network defaults to mainnet and requires user confirmation if not explicit. It does not explain address or getter, but these are largely self-evident from the tool name and context. The description adds partial meaning beyond the schema.
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-resource pair: 'Executes an autonomous-agent getter' and clearly indicates it returns the getter result. The 'Raw hub read' preamble adds low-level context. It does not explicitly differentiate from sibling tools (e.g., obyte_dry_run_aa or obyte_get_aa_state_vars), but the operation is distinct enough to be inferred.
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?
Provides no guidance on when to use this tool versus alternatives. The only operational guidance is the network selection: confirming which network when the user has not been explicit. This is a parameter-handling note, not usage guidance. There is no mention of scenarios where a sibling should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavioral context beyond those: this is a raw hub read, the server serves two networks, the network parameter defaults to mainnet, and the agent should confirm ambiguity before calling. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears in the first sentence, and the network caveat follows naturally. Every sentence earns its place, and there is no filler or repetition of annotation fields.
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?
For a simple two-parameter read with strong annotations, the description covers the critical invocation detail: network ambiguity and defaulting behavior. Since there is no output schema, the return shape is not described, and the relationship to obyte_get_attestation is unaddressed, but what an agent needs to call the tool correctly is largely present.
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?
The input schema has 0% description coverage, so the description must compensate. It does add meaning for the network parameter, including the default value and confirmation requirement. However, it adds nothing about the address parameter beyond what the schema's type and length constraints imply, leaving only 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 clearly states the action and resource: 'Raw hub read. Returns attestations associated with one address.' This gives a specific verb, resource, and scope. However, it does not explicitly differentiate itself from the similarly named sibling obyte_get_attestation, so it falls short of a 5.
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?
The description provides network-selection guidance but no when-to-use-this-vs-an-alternative guidance. It never mentions obyte_get_attestation or explains when an agent should prefer this tool over its siblings. The 'Raw hub read' phrase hints at use cases but does not constitute explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context about the dual-network setup and default network, but it repeats the schema's maxItems limit and does not disclose response format, missing-feed behavior, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears in the first sentence, and the network guidance is essential. It loses a point for repeating the maxItems constraint already present in the schema, making the description slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the critical network ambiguity and the basic read semantics, and the annotations cover safety. But it leaves 'ifnone' undefined, gives no hint about the shape of the returned data, and provides no guidance for choosing among the many sibling get/fetch tools.
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 carry the parameter meaning. It explains oracles as oracle addresses, feed_name as a feed name, and network with choices/default. However, the 'ifnone' parameter is not explained at all, and the 10-entry limit merely restates the schema's maxItems constraint.
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 action ('reads a data feed') and resource ('by oracle addresses and feed name'). It is clear and the 'Raw hub read' hint suggests a low-level operation, but it does not explicitly distinguish this tool from sibling read tools such as obyte_get_attestation or obyte_get_history.
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 gives explicit operational guidance: the server serves both Obyte networks, the network parameter must be mainnet/testnet, it defaults to mainnet, and the agent should confirm the network when the user has not specified it. It does not name alternatives or say when not to use this tool, but the context is clear enough for a raw read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful behavioral detail beyond that: base/null maps to GBYTE, unknown assets fall back to sanitized asset characters, and the dual-network behavior is disclosed. This exceeds what the annotations alone would tell an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by edge-case behavior and the network caveat. The network guidance is longer but earns its place because it prevents a common mistake. Little is wasted, though the registry wording could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with no output schema, the description covers the core mapping behavior and the main network ambiguity. It does not explain what the actual return value looks like, how the registry is selected, or how token_registry_address interacts with the default behavior, so an agent still has some uncertainty before calling.
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 carries most of the parameter meaning. It explains asset behavior well and explains the network parameter including default and confirmation guidance. However, token_registry_address is only vaguely referenced as 'the selected registry' and is never directly described, leaving one parameter ambiguous.
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 opens with a clear verb and resource: it resolves an Obyte asset id to a token symbol through a registry. It adds useful specifics about base/null mapping to GBYTE and fallback behavior. However, it does not explicitly differentiate this from related sibling tools such as obyte_get_asset_by_symbol or obyte_resolve_asset.
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 a clear operational rule for choosing a network: pass mainnet or testnet, default to mainnet, and confirm with the user if unspecified. This is helpful but it never mentions when to prefer this tool over sibling resolution tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond that: the raw hub read nature, the default network behavior, and the fact that amounts are raw integers in smallest units. This is useful disclosure that annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The two additional paragraphs address network selection and amount formatting, both of which are necessary for correct use. Slight redundancy exists with 'Raw hub read' followed by 'Returns', but overall the text is efficient and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return semantics; it does cover the important raw-integer amount behavior and display_total guidance. However, it leaves ambiguities: what exactly constitutes an 'AA response', what happens if neither aa nor aas is provided, and the overall response shape. These gaps matter for an uncomplicated but under-specified tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden of explaining parameters. It explains the aa/aas distinction ('one' vs 'up to 20'), the network enum values, and the default behavior when network is omitted. It does not explicitly state that at least one of aa or aas should be provided, but it does add meaningful meaning to all three parameters.
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 clear verb ('Returns') and a specific resource ('AA responses') with explicit scope (one address or up to 20 addresses). It also adds the qualifier 'Raw hub read', which helps differentiate it from analysis-oriented siblings, though it does not define what an 'AA response' is in detail.
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 useful contextual guidance about selecting the network and confirming it with the user when unspecified. However, it does not state when to prefer this tool over siblings like obyte_get_aa_response_chain or obyte_analyze_aa, nor does it provide explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior. The description adds genuinely useful context beyond those hints: this is a raw hub read, the server serves both Obyte networks, the default is mainnet, and the agent should confirm the intended network with the user when it is not explicit. This is meaningful behavioral transparency.
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 is short and well-structured. The main purpose is front-loaded in the first sentence, and the network paragraph is necessary due to the dual-network server behavior. There is no filler or repetition of schema details.
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?
For a read-only tool with strong annotations, this is nearly complete: it states what is returned, the input scope, and the important network behavior. The main gaps are the lack of an output schema and a missing explicit note about requiring one of base_aa or base_aas, but these are minor for this raw read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the semantic load. It explains the network parameter's allowed values, default, and confirmation requirement, and clarifies that base AAs can be provided as a single value or a list up to 20. It does not fully spell out whether base_aa and base_aas are mutually exclusive, but it still adds significant meaning beyond the bare schema.
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 clearly states the operation: 'Returns AAs derived from one base AA or up to 20 base AAs' and labels itself a 'Raw hub read.' This identifies the specific resource and action. It does not explicitly compare with sibling tools, so it misses the top score.
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 'Raw hub read' label and the description of what is returned imply when this tool is appropriate. The network guidance adds useful calling context, but there is no explicit direction about when to prefer this tool over siblings like get_aa_responses or execute_getter, and no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the server serves both networks at once, the default is mainnet, and confirmation is required when network intent is unclear.
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 is tight and front-loaded: a one-line purpose statement, then focused network instructions. Every sentence earns its place, and the critical network ambiguity guidance is included without fluff.
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?
For a tool with only two parameters, rich annotations, and no output schema, the description covers the main decision points: which network to use, the default, and when to ask the user. It does not describe the response shape, but the term 'definition' gives enough expectation for a simple read operation.
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 fully explains the network parameter, including allowed values and default behavior, but gives only minimal implicit meaning for the required address parameter ('definition of one Obyte address') without describing format, validation, or expected address style.
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 clear action and resource: 'Raw hub read. Returns the definition of one Obyte address.' This is specific enough to distinguish from analysis-oriented siblings like obyte_analyze_address, but it does not explicitly name any sibling or explain what 'definition' includes.
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?
Provides concrete usage context for the network parameter, including the two valid values, the default, and a strong instruction to confirm the network when the user has not specified it. It does not compare against alternative tools or give when-to-use versus 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavioral context beyond that by explaining the dual-network behavior, the mainnet default, and the need to confirm network choice. No contradiction exists between the description and annotations.
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?
Three sentences, all of which add value. The core action is front-loaded as 'Raw hub read', followed by the network requirement and user-confirmation guidance. There is no filler or repetition of schema details.
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?
The description covers the main non-obvious contextual issue, network selection, and is backed by annotations that establish safety and idempotency. It does not describe the joint response shape or explicitly separate this raw read from sibling analysis tools, but for a simple hub read with no output schema the provided context is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining that 'unit' is a unit hash and specifying how to pass the network parameter, including the mainnet/testnet values and the default. It could go further by defining what a 'joint' is, but the essential parameter semantics are addressed.
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 opens with 'Raw hub read' and states it 'Fetches the joint for one unit hash from the selected hub', which is a specific verb, resource, and input. It conveys a low-level read operation, but it does not explicitly contrast this tool with sibling tools like obyte_analyze_unit or obyte_get_history.
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?
The description gives clear usage context: the server serves both Obyte networks, the network parameter selects which one, and the default is mainnet. It also instructs the agent to confirm the user's intended network when not explicit, which is actionable guidance, though it lacks explicit when-to-use vs alternatives statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: it is a raw hub read, results are returned only 'when available,' and the same server serves both mainnet and testnet. This goes beyond the structured annotations without contradicting them.
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 is compact, front-loaded with the core action, and uses a short dedicated network paragraph for crucial disambiguation. Every sentence carries useful information and there is no 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?
For a simple two-param read tool, the description covers the main selection pitfalls and the network ambiguity. It does not specify the exact return shape or what 'when available' means in practice, but the absence of an output schema and the low operational complexity keep this from being a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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's allowed values, default behavior, and ambiguity, and it restates the address count range. It does not explain address format details, but the schema already constrains length and the required field is clear.
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 clearly states the tool returns profile units for a small set of addresses and labels itself a 'Raw hub read,' which conveys the nature of the operation. It does not explicitly contrast itself with sibling read tools, but the resource and verb are specific enough that an agent can infer what it does.
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?
The description gives clear practical guidance on selecting the network, including the default and an explicit instruction to confirm the network with the user when it is not stated. It does not discuss when to prefer this tool over sibling tools, but the network ambiguity handling is valuable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only, idempotent, and non-destructive behavior. The description adds useful context beyond that: the mainnet default comes from obyte.js, custom/testnet registries require explicit user trust, and the server serves both networks at once.
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 is compact, front-loaded with the core purpose, and then provides necessary network-selection context. Every sentence adds value; there is 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?
The description covers purpose, network selection, default behavior, trust requirements, and pre-call confirmation. The main gap is the under-explained token_registry_address parameter, but for a simple read-only getter with strong annotations, the description is otherwise complete.
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 well, including allowed values and default behavior, but only vaguely hints at token_registry_address through 'custom and testnet registries must be explicitly trusted' without explicitly documenting that parameter's purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('returns') and a specific resource ('token registry address for the selected network'). It also clarifies the mainnet/testnet scope, making it easy to distinguish from the many other get_* sibling tools.
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?
The description gives explicit guidance on selecting the network, explains the default behavior, and instructs the agent to confirm the network when the user has not made it explicit. It does not mention alternative tools, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds substantial behavioral detail beyond those: network defaults to mainnet, state vars are sorted by key and may be truncated, amounts are raw smallest units, and output includes a decimals-aware balance_summary. It also warns never to show raw integers and points to resolver tools for decimal conversion. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal, but every section earns its place: the first paragraph states purpose and key outputs, the second addresses the dual-network caveat, and the third provides essential unit/display handling. Information is front-loaded and logically grouped, though the amount-handling paragraph is dense and could be tightened.
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?
With no output schema, the description carries the burden of explaining return contents. It covers balance_summary, state vars, optional responses, truncation, raw units, and network selection, and even gives explicit actions for decimal conversion. It does not fully specify the shape of balance_summary or the AA response object, but for a state-inspection tool this is sufficient context.
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?
Since schema description coverage is 0%, the description must compensate. It meaningfully explains the network parameter, state_var_prefix usage, and include_responses. It implies the address parameter is the AA address. However, include_balances is never mentioned as a toggle, and the exact filtering semantics of state_var_prefix are not fully described. This is partial compensation, not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('summarizing'), a specific resource ('Obyte autonomous agent'), and lists concrete outputs (balances with balance_summary, state vars by prefix, optional AA responses). It also positions itself as the recommended tool for AA debugging, which clearly distinguishes it from siblings like obyte_analyze_address or obyte_get_aa_balances without needing to open their schemas.
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?
The description says it is 'Recommended tool for summarizing an Obyte autonomous agent' and 'Use for AA debugging or state inspection', giving clear context for when to invoke it. It also instructs the agent to confirm mainnet vs testnet when the user hasn't specified, which is an actionable usage rule. However, it does not explicitly name sibling alternatives or say when NOT to use them, so some inference is still required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly annotation, the description discloses important behavioral traits: it is a simulation that does not sign or broadcast, is not retried by default, and is not idempotent. It also explains network defaulting and output amount units, which is substantial context that annotations do not cover.
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 is organized into three focused paragraphs, each earning its place: core behavior, network handling, and output formatting. Key facts are front-loaded and there is 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?
Given the absence of an output schema, the description provides valuable context about output amounts and display preferences. It lacks a detailed explanation of the full return structure, but the core call semantics and network handling are sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description compensates well by explaining the 'network' parameter (choice, default, and confirmation requirement) and 'trigger' (JSON trigger payload). 'address' is not explicitly described, but its role as the autonomous agent address is implied by the tool name and description.
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 clearly states a specific verb and resource: 'Simulates triggering an autonomous agent with a JSON trigger payload.' It also clarifies what the tool does not do ('does not sign or broadcast'), but it does not explicitly contrast itself with sibling tools like obyte_prepare_aa_dry_run, so it lacks full sibling differentiation.
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?
Provides clear context: it explains the dual-network behavior, instructs to confirm the network when the user is not explicit, and warns against showing raw integers. However, it does not explicitly state when to use this tool versus alternatives such as obyte_prepare_aa_dry_run, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses meaningful behavior: symbols are uppercased before lookup, base units like GBYTE and MBYTE resolve specially, and the network defaults to mainnet. This materially helps an agent predict behavior.
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 is compact and well-structured: core behavior first, then network guidance in a separate paragraph. Each sentence adds necessary information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description handles the most important ambiguity—dual network support—and documents the default, but it omits semantics for the optional token_registry_address parameter and any information about return values or error cases. This is adequate for simple calls but not fully complete for the full parameter set.
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 'symbol' semantics (uppercasing and base aliases) and the 'network' enum/default, but never explains 'token_registry_address' beyond the vague phrase 'selected registry'. Partial compensation with a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific operation: resolving a token symbol to an Obyte asset id via a registry. It clearly differentiates the tool from the reverse lookup sibling obyte_get_symbol_by_asset by naming the direction of resolution.
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?
Provides explicit invocation context: how to choose between mainnet and testnet, the default behavior, and an explicit instruction to confirm the network when the user hasn't specified one. It does not explicitly mention sibling alternatives, but the usage conditions for this tool are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuine behavioral context beyond that: the dual-network serving model, the mainnet default, config precedence details, and the actionable instruction to mention update_available to the user. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense paragraphs: the first front-loads the return contents and usage timing, the second covers parameter semantics and user-confirmation protocol. Each sentence earns its place; slightly long but packed with useful information rather than 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?
For a single-optional-parameter tool with no output schema, the description is thorough: it lists the return contents, states when to call it, explains the network parameter, the default behavior, and a user-interaction rule. Minor gaps like response format examples or error behavior exist but are not critical given the tool's simplicity and annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the full burden for the single network parameter. It compensates well by explaining the accepted values ('mainnet'/'testnet'), the default when omitted, and guidance to confirm the user's intent before calling. This adds real semantic value beyond the bare enum in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('effective MCP runtime configuration') followed by a concrete enumeration of the contents: default network, per-network hub URL, token registry, config precedence, limits, witnesses cache metadata, and update availability. The topic is clearly distinct from all sibling tools, which deal with balances, attestations, history, and other data queries, so no confusion is possible.
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?
The description gives explicit when-to-use guidance: 'Use before other calls when network selection matters.' It also instructs the agent to confirm the intended network with the user before calling when it wasn't explicit. It doesn't name alternatives or when-not-to-use conditions, but no sibling tool competes for this purpose, so clear context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/destructiveHint annotations, the description explicitly discloses that the tool does not sign, broadcast, or mutate local state, and that dry-run tools are not marked idempotent and are not retried by default. It also discloses the network default and dual-network behavior, adding substantial operational context beyond annotations.
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 is front-loaded with the most decision-relevant information - recommendation, safety, and network behavior - and every sentence carries practical value. It is long, but each section addresses a distinct fail mode: no side effects, retry behavior, network ambiguity, and unit misuse.
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?
The description gives enough for safe and correct invocation: what it does, how to select network, how to express amounts, what side effects to expect, and how to present raw output amounts. It is missing only a fuller explanation of the return payload structure and the address/trigger shape, which would matter more given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, this description compensates well: it explains the network parameter, its default, and the need to confirm intent, and it emphasizes raw-unit conversion for trigger amounts. It does not explicitly document the address parameter or the exact shape of the trigger payload, but the core ambiguity around units and network is resolved.
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 action - simulating an Obyte autonomous-agent trigger - and names the resource, the selected network's hub. It does not, however, explicitly distinguish itself from the similar sibling obyte_dry_run_aa; calling itself 'Recommended' is helpful but not a clear differentiator.
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 clearly frames the tool as the recommended choice for simulating an AA trigger, notes that it does not sign/broadcast, and gives a practical network-confirmation instruction. It lacks an explicit 'use X instead when...' or when-not-to-use list, so it stops short of fully routing against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context beyond these: the dual-network nature of the server, the mainnet default, and the 'raw' nature of the read. No contradictions with annotations were found.
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?
Two compact paragraphs deliver the core purpose first and the network instructions second. Every sentence earns its place, with no filler, repetition, or unnecessary detail.
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?
For a simple read operation with no output schema, the description provides the essential information: what is looked up, the three required keys, and how to handle network selection. It doesn't describe return shape or error cases, but 'raw hub read' combined with the annotation set gives enough context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 carry the parameter-explanation burden. It does so by tying the three required parameters together as a lookup key ('by attestor address, field, and value') and by fully explaining the optional 'network' parameter's allowed values and default behavior. It does not detail address/value formats, but it meaningfully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Raw hub read. Looks up one attestation by attestor address, field, and value.' This uses a specific verb and resource, and explicitly says 'one' to differentiate it from the plural sibling 'obyte_get_attestations' without needing to inspect schemas.
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?
The description provides clear network usage guidance: this server serves both Obyte networks, the 'network' parameter defaults to mainnet when omitted, and the agent should confirm which network the user means if not explicit. It does not explicitly name alternatives or exclusion conditions, but it gives practical context for when to call and how to proceed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior, so the description's burden is lighter. Still, the description adds valuable behavioral facts: symbols are uppercased before lookup, base aliases have fixed decimals, registry data is untrusted metadata, and network behavior defaults to mainnet. These details materially affect how results are interpreted and are not available in the annotations or schema.
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 is organized into two compact paragraphs: the first states the core behavior and base-unit decimals, the second addresses network selection. Every sentence earns its place, and the important network caveat is separated rather than buried. There is no filler or repetition of schema/annotation fields.
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?
For a simple read-only lookup, the description covers the required input, normalization behavior, base-unit values, and network selection. The main gap is the undocumented token_registry_address parameter, which may matter for custom registry lookups. The return format is not described, but that is less critical for a tool whose result is inherently a small numeric value.
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 for the schema's lack of prose. It does explain symbol_or_asset well (base aliases/registry symbols, uppercase normalization) and network well (mainnet/testnet, default, confirmation). However, the optional token_registry_address parameter is never described, so the agent cannot learn when or why to provide it from the description. This missing parameter keeps the score at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence ties a specific verb ('Returns decimals') to a defined resource ('base aliases or a registry-known token symbol/asset') and directly maps to the symbol_or_asset parameter. This distinguishes the tool from siblings like obyte_get_asset_by_symbol and obyte_get_symbol_by_asset, which address a different lookup direction. The unit-precision detail further clarifies exactly what the caller receives.
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 does not explicitly name sibling alternatives or say when not to use this tool, but it gives strong operational guidance: the server serves both Obyte networks, network selection must be explicit when ambiguous, and the default is mainnet. The instruction to confirm the network with the user before calling when it is not explicit is a concrete usage rule. Lacking explicit when-to-use/when-not-to-use versus sibling tools prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by explaining the dual-network behavior, the mainnet default, the witness-cache fallback, and the raw integer amount semantics. It also warns about displaying raw integers and points to helper tools for decimal resolution. No contradictions with annotations.
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?
Front-loaded with the core purpose, then organized into labeled paragraphs for network and amounts. Every sentence adds actionable guidance, and the formatting makes the long description easy to scan. No filler or repetition of schema facts.
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?
Covers the main traps an agent will face: network ambiguity, raw unit formatting, and witness handling. The only notable gap is the unexplained 'update_witnesses' parameter and, since there is no output schema, a bit more explicit return-shape detail would improve completeness.
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 does explain 'network', 'addresses' count, and 'witnesses' fallback, but 'update_witnesses' is never described, leaving its meaning entirely to inference. This partial coverage keeps the score at 3 rather than higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Returns history for 1 to 20 addresses.' The 'Raw hub read' label clearly distinguishes this low-level access from higher-level sibling tools like obyte_analyze_address or obyte_get_portfolio_summary. The count range also sharpens the scope.
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?
Provides clear operational context: raw hub read, witness cache behavior, and explicit network selection guidance with a warning to confirm the user's network before calling. It does not explicitly name alternatives or exclusion criteria, but the raw-read framing makes its place among siblings reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context beyond those annotations by explaining that this server serves both Obyte networks at once, that omission defaults to mainnet, and that the value is only what the selected hub knows. No contradiction with annotations.
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 is compact and front-loaded: the first sentence states the operation, and the second paragraph handles the one non-obvious parameter behavior. Every sentence contributes either purpose or invocation guidance; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter, read-only, idempotent tool with no output schema, the description covers the operation, the key dual-network gotcha, the default, and a pre-call confirmation rule. Nothing necessary for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 explain the lone network parameter itself. It does so thoroughly: it names the two enum values, states the default when omitted, and instructs the agent to confirm an unspecified network before calling. This is strong compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Raw hub read' and then states a specific verb and object: 'Returns the last main chain index known by the selected Obyte hub.' This precisely identifies the operation and scope, and the 'raw hub read' framing separates it from the more analytical sibling tools such as obyte_analyze_address or obyte_get_network_info.
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?
There is no explicit when-to-use or when-not-to-use guidance and no alternative sibling is named. The main usage direction is the network-selection rule, including a good instruction to confirm the network if it was not made explicit, but that addresses parameter handling rather than tool choice; usage context is only implied by 'Raw hub read.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, and the description adds meaningful behavior beyond that: it returns raw ledger integers in smallest units, defaults to mainnet, requires network confirmation when unspecified, and instructs agents never to surface raw integers to users. This operational context goes well beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is longer than a bare sentence but stays scannable with 'Network:' and 'Amounts:' blocks, and every paragraph earns its place by adding operational guidance. It is front-loaded with the core definition before usage caveats. Minor redundancy is acceptable.
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?
For a two-parameter read with no output schema, the description covers the critical invocation decisions—which network to hit and how to interpret raw units—and points to siblings for deeper analysis. It hints at 'display_total fields' but does not enumerate the response shape, so an agent cannot know the exact return structure in advance. Despite that gap, it is sufficient to call the tool correctly and handle its output safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, forcing the description to carry parameter meaning. It explains the network parameter in full: the two enum values, the mainnet default, and the instruction to confirm with the user. Address semantics are only described indirectly as 'one autonomous agent address,' leaving some detail to the schema's min/max length constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'Raw hub read' plus 'Returns balances held by one autonomous agent address' names a specific verb, resource, and scope. It explicitly contrasts with obyte_analyze_aa in the same breath, so an agent can tell this raw AA-balance tool apart from the decimals-aware sibling.
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?
The description directs agents to obyte_analyze_aa when a decimals-aware summary is wanted, and it gives concrete network-selection guidance including confirming the user's intended network before calling. It does not, however, discuss when to prefer this over obyte_get_balances or other balance-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive. The description adds meaningful behavior: raw smallest units, sorted map-like output, 128-character prefix limit, network default behavior, and the instruction to never show raw integers directly. This goes well beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries relevant information: purpose, bounds, output behavior, network handling, and amount formatting. It is front-loaded with the core purpose and then layers necessary edge-case guidance without redundancy.
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 there is no output schema and no parameter descriptions, the description is quite complete: it covers network selection, raw units, output sorting, and prefix length. Minor gaps remain around the exact interpretation of var_prefix_to and var_prefix_from, such as whether the range is inclusive, but the overall guidance is sufficient for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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, defaulting to mainnet, and clarifies the prefix/range boundary options and length constraint. The address parameter is semantically obvious from the tool purpose, and var_prefix_to/from are reasonably inferable from the prefix/range mention, though not fully specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Raw hub read' and states exactly what it returns: autonomous-agent state variables, optionally bounded by prefix/range. This clearly identifies the resource and distinguishes it from related tools like balance or attestation readers, so an agent can tell it apart from siblings.
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?
The description gives clear operational context: it explains how to select the network, notes the mainnet default, and instructs the agent to confirm the network with the user when it is not explicit. It also provides formatting guidance for amounts. It does not explicitly name alternative tools or when not to use it, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses that data comes from a centralized explorer rather than the hub, may lag, and is capped at 100 holders per call. It also explains raw amount semantics and display formatting, giving the agent important behavioral context that annotations alone would not 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 is front-loaded with the recommended use case and then organized into clear labeled paragraphs for network and amount handling. Every sentence earns its place; no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description explains what is returned: holders sorted descending, raw and display amounts, and total supply. It also covers network behavior, a data-source caveat, and the critical raw-amount formatting rule. An agent has enough to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description carries the param documentation burden. It clearly explains asset_or_symbol as a token symbol or 44-character asset id, and network as mainnet/testnet with a default. Limit is only implied by 'Up to 100 holders per call,' but the schema already defines its min/max, so the combined picture is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: it gets asset holders, sorted by balance descending, with raw/display amounts and total supply. It also gives trigger phrases like 'who holds', 'top-holders list', and 'distribution/concentration', making the tool easy to distinguish from sibling tools.
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 explicitly states when to use the tool: whenever the user asks about holders, top-holders, or token distribution. It also gives network-selection guidance and warns to confirm the network if unspecified. However, it does not explicitly name alternatives or say when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, non-destructive, and idempotent, and the description adds substantial behavioral detail beyond that: it serves both Obyte networks at once, amounts are raw smallest units, output is hub data in a stable JSON envelope, and raw integers must not be shown to users. This is rich, non-obvious context that helps the agent invoke and interpret results correctly.
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 is front-loaded with the key purpose, then adds network and amount guidance in logically grouped paragraphs. Every sentence carries functional weight, including the user-facing formatting rule. It is detailed but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description tells the agent what kind of output to expect ('stable JSON envelope'), how to handle networks, and how to handle raw amount values. It also give a concrete trigger for invocation. This is enough for reliable selection and correct calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. It explains the unit hash format ('44-character base64 string, usually ending in "="'), the network parameter values and default, and the behavior of include_aa_response_chain ('follows the AA response chain for trigger units'). The agent receives actionable meaning for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is explicit: it is the 'Recommended tool whenever the user pastes an Obyte unit hash... or asks about an Obyte transaction', and it names its core action: 'Fetches the joint and, when requested, follows the AA response chain'. This clearly identifies both the resource and the operation, making it distinguishable from the many sibling tools.
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?
The description gives strong usage context: when to use it, what it does, and how to handle network ambiguity ('If the user has not made the network explicit, confirm which network they mean before calling'). It does not explicitly list exclusions or compare itself to siblings like obyte_get_joint, but the 'Recommended tool... whenever' phrasing effectively establishes its primary role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: this server serves both mainnet and testnet at once, the network parameter defaults to mainnet when omitted, and the agent should confirm user intent on network selection. No contradiction with annotations.
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 is compact and well-structured: the first paragraph states purpose and boundary, while the second focuses on the network parameter and the required confirmation step. Every sentence earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no required fields, and read-only/idempotent annotations, the description is complete enough. It covers purpose, usage boundary, parameter behavior, defaults, and a key prerequisite. The lack of an output schema is acceptable because the description states what is returned ('peers known by the selected hub') and the tool is simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 for the network parameter. It does so thoroughly by explaining that both networks are served, naming the exact values, stating the default behavior, and instructing the agent to disambiguate user intent. This adds substantial meaning beyond the raw enum in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('peers known by the selected Obyte hub'), and frames the tool as a 'Raw hub read' for network diagnostics. It explicitly distinguishes the tool from address analysis, which separates it from many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case ('Use for network diagnostics, not address analysis') and gives a concrete precondition: confirm which network the user means before calling when it was not made explicit. This is strong routing guidance even without naming a specific alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds non-obvious behavior: results are cached for 10 minutes per network+hub unless update=true, and the server serves both networks at once. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by cache behavior and network instructions. Each sentence earns its place and no information is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only tool with no required parameters and both optional parameters explained, the description is complete. It covers purpose, network selection, default behavior, caching, and a user-confirmation rule. No output schema is present, but 'Returns witnesses' sufficiently states the return intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: network is given an enum context plus the default behavior, and update is explained as a cache-bypass switch. Both parameters gain practical meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states 'Raw hub read. Returns witnesses for the selected network,' naming a specific verb, resource, and scope. It also distinguishes this from sibling tools by framing it as a direct, unprocessed hub read.
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?
The description gives clear operational guidance: choose 'mainnet' or 'testnet', explains the mainnet default, and instructs the agent to confirm the network with the user when it is not explicit. It does not, however, mention alternative sibling tools or explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description reveals concrete behavior: symbols are uppercased before lookup, asset IDs are case-sensitive, network defaults to mainnet when omitted, unregistered symbols return null asset/symbol with a note, and registry mappings are only convenience metadata. These details materially affect how an agent should interpret results and make the tool safer to use.
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 is front-loaded with the tool's role and input formats, then covers return behavior and network selection in compact paragraphs. Every sentence contributes either a behavioral rule or an actionable instruction; no filler or repetition is present.
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?
For a read-only resolver with no output schema, the description covers accepted inputs, return fields on both success and missing-symbol cases, network selection, and a safety caveat about registry legitimacy. The main gap is the undocumented `token_registry_address` parameter, which prevents the description from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well for `value` by defining accepted formats and case rules, and for `network` by listing the enum values, default, and a confirmation requirement. However, `token_registry_address` is never mentioned, leaving its purpose and relationship to 'selected network's registry' unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence says it is the 'Recommended tool for resolving an Obyte asset id (44-character base64 string) or token symbol' in the network's registry, giving a specific verb, resource, and accepted input forms. It also distinguishes itself as recommended and names the related obyte_get_decimals_by_symbol_or_asset as an alternative, so an agent can tell when this tool is intended.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Always call this (or obyte_get_decimals_by_symbol_or_asset) before presenting amounts of unknown assets to users.' It also instructs the agent to confirm which network the user means when it isn't explicit, and states the default. That is actionable when-to-use guidance with an alternative, though it doesn't exhaustively enumerate when not to call the sibling symbol/asset lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context beyond those annotations: the server serves both networks at once with mainnet as default, the output is a stable JSON envelope that may be truncated, and raw ledger amounts are integers in smallest units that must never be shown directly to users. These are non-obvious behavioral traits that materially affect how an agent should use the result.
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?
Though longer than average, the description is tightly structured: purpose/usage, return envelope, network guidance, and amount-handling are each clearly scoped. Every sentence adds decision-relevant information, and the critical warnings about network and decimals are front-loaded into their own sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five params, no output schema, and a dual-network server, the description covers all esential aspects: address input format, network selection and default, output shape and truncation, and decimal-handling instructions. It also names sibling tools for compensating operations. The only minor gap is not explaining the 'profile units' component, but this is subordinate to the overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains the address format (32-character base32), the network parameter values and default, and the return semantics of the booleans via 'optional definition, profile units, attestations, and bounded history.' However, not every boolean is explicitly mapped (e.g., include_history isn't directly tied to 'bounded history'), and 'profile units' has no corresponding parameter, leaving minor ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Analyze') and resource ('an Obyte address') and clearly enumerates what it returns: decimals-aware balance_summary, optional definition, profile units, attestations, and bounded history. It also distinguishes itself from sibling tools by calling itself the 'recommended first tool' for wallet/balance/account questions and by saying 'Use this instead of several raw calls.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: whenever a user pastes an Obyte address or asks about a wallet, balance, or account. It provides an exclusion by recommending it 'instead of several raw calls,' and it names alternative tools for decimal resolution (obyte_resolve_asset, obyte_get_decimals_by_symbol_or_asset). It also adds a critical precondition: confirm the network if the user wasn't explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive, so safety is covered. The description adds valuable behavioral context beyond annotations: the server serves both Obyte networks, network defaults to mainnet, and output amounts are raw integers in smallest units. It also warns against showing raw integers, which is exactly the kind of behavioral trap an agent needs disclosed.
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 is structured into clear paragraphs: purpose and alternative, network handling, and decimal semantics. Every sentence carries operational value, and the most important scoping information is front-loaded. It is long enough to be useful but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still prepares the agent for critical response semantics by mentioning raw integers, display_total fields, and decimal resolution steps. It covers network ambiguity, limits, and alternative tool routing. No required context for a correct call appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 fully explains the network parameter including defaults and the need for user confirmation. It mentions the 1-to-20 address limit for the addresses parameter but does not describe address format or constraints beyond what the schema already encodes. Given the schema is silent, this is a meaningful but not complete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: "Fetches balances for 1 to 20 addresses" and labels itself a raw hub read. It clearly distinguishes itself from obyte_get_portfolio_summary by offering that sibling as the agent-friendly alternative. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs agents to use obyte_get_portfolio_summary when summaries with decimals-adjusted display totals are preferred. It also gives actionable network-selection guidance and instructs the agent to confirm the network with the user when it is not explicit. This is strong when-to-use and routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the call as read-only, idempotent, non-destructive, and open-world, and the description adds substantial behavioral context beyond those hints: it explains the return shape (raw balances plus totals_by_asset), how display totals are divided by 10^decimals, the network default, and the raw integer unit convention. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than one sentence, but every sentence earns its place: the first paragraph gives the purpose and sibling distinction, the second gives a critical network-handling rule, and the third prevents harmful unit misinterpretation. The layout with short labeled paragraphs keeps it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by stating the return fields, the decimals/display-total behavior, and the raw integer units. It also covers the dual-network constraint and tells the agent when to call other helpers to resolve decimals. This is sufficiently complete for correct invocation and safe user-facing use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does well: it clarifies network choice and default, resolve_symbols's effect on registry lookups, and the 20-address limit for addresses. However, token_registry_address is only indirectly referred to via 'registry lookups' and is not explicitly explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('summarizing balances for up to 20 addresses') and explicitly distinguishes this tool from raw get_balances, recommending it for user-facing balance explanations. This gives an agent clear signal about what the tool does and how it differs from its most similar sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool for user-facing balance explanations, not raw get_balances, and gives a concrete cap of 20 addresses. It also instructs the agent to confirm the network with the user when it is not explicit, which is important because the server serves both mainnet and testnet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![obyte-mcp MCP server](https://glama.ai/mcp/servers/Taump/obyte-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Taump/obyte-mcp)

Score Badge

Copy to your README.md:

[![obyte-mcp MCP server](https://glama.ai/mcp/servers/Taump/obyte-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Taump/obyte-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Taump/obyte-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server