ORDnet MCP Server

Official

by ORDNET

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

Server Quality Checklist

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

Latest release: v3.1.0
Disambiguation2/5
Several tools are near-duplicates: ordnet_inscribe_html/json/text are all one-step broadcast tools differing only by content type, and ordnet_domain_register_sns/opns duplicate ordnet_domain_register with a protocol parameter. While descriptions are clear, the redundant convenience wrappers create ambiguity about which tool to select.
Naming Consistency3/5
All tools share the ordnet_ prefix and snake_case, but the pattern is inconsistent: some follow topic_verb (wallet_init, domain_check), others verb_topic (search_inscriptions, generate_wallet). Suffixes like _env, _sns, _html add further irregularity.
Tool Count2/5
45 tools is well above the 25-tool threshold, and several are redundant convenience wrappers (inscribe_html/json/text, domain_register_sns/opns) that could be consolidated. The breadth of domains partially justifies the count, but it still feels heavy.
Completeness3/5
The server covers wallet, inscriptions, domains, payments, identity, x402, and indexing thoroughly. Minor gaps include no way to list inscriptions owned by an address or retrieve address transaction history, but most core workflows (create, broadcast, transfer, read, search) are covered.
Average 4.2/5 across 45 of 45 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on August 13, 2026
- 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 destructiveHint=true and readOnlyHint=false. The description adds the return format ({ txid, inscriptionId, domain }), which provides some behavioral transparency, but it does not mention side effects like on-chain transactions or fund spending beyond what annotations already signal.
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 concise, front-loaded, and includes clearly labeled Args and Returns sections. The only minor detractor is the inaccurate fee default, which is a semantic issue, not a structural one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives parameters and a return shape, but it lacks essential context for a registration tool: prerequisites (e.g., wallet setup), on-chain effects, and a clear differentiation from other registration tools. No output schema exists, so the return info is helpful but insufficient for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description incorrectly states the default for feePerByte (0.2) while the schema says 0.15. This actively misleads, so the score is lowered to 2.
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 ('registration') and resource ('SNS domain'), for example '.sats, .btc, etc.' This clearly distinguishes it from sibling tools like ordnet_domain_register and ordnet_domain_register_opns.
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 implies usage for SNS domain registration via the title and text, but there is no explicit statement of when to use this tool over alternatives. No exclusions or when-not-to-use guidance is provided.
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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the return structure '{ inscriptions: [...], count }' which is useful since no output schema exists. However, it does not disclose details like pagination behavior, search matching rules, or the meaning of 'count' (total matches vs returned count).
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 core one-sentence description is concise and front-loaded. The Args and Returns sections add useful output context but repeat the schema parameter details, introducing minor redundancy. Overall it is appropriately sized, not overly verbose.
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 simple 3-parameter search tool with no output schema, the description covers the essential return structure. However, it leaves ambiguity around 'count' and does not explain search behavior (e.g., wildcard, case sensitivity) or when to use this over other search tools. Missing output schema would benefit from more explicit return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters documented. The description's Args section largely duplicates the schema without adding new meaning. It provides example content type 'text/html' in the schema but not in the description, so no additional value is given.
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 a specific action: 'Search for inscriptions on the BSV blockchain.' This is distinct from sibling tools like ordnet_get_inscription (likely retrieving a single inscription) and domain search tools. The verb 'Search' and resource 'inscriptions' make the purpose unambiguous.
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 no guidance on when to use this tool versus alternatives. There is no mention of using ordnet_get_inscription for direct lookups or ordnet_content_types for available filters. The description simply states the action without any contextual direction.
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?
It discloses the action ('creates and broadcasts'), the need for an initialized wallet, and the return shape. This adds context beyond annotations, but it omits details about spending funds or irreversibility, and does not clarify what 'destructiveHint=true' means for this operation.
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 a concise purpose sentence followed by labeled sections (Args, Returns, Requires). It is well-organized and free of unnecessary prose, though the Args section redundantly duplicates schema content.
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 4-parameter tool with an object return and no output schema, the description covers purpose, parameters, return, and a prerequisite, making it functionally usable. Gaps remain: it does not mention alternatives to this generic registration tool versus specialized siblings, and the parameter default error undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the description's parameter list adds no new meaning. Worse, it states `feePerByte` default as 0.2 while the schema specifies 0.15, creating a factual conflict that could mislead an agent.
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 it 'Registers a new SNS/OPNS domain on the blockchain' and 'Creates and broadcasts a domain registration inscription,' using a specific verb and resource. It distinguishes itself from domain check/info/search tools and explicitly mentions both SNS and OPNS protocols. No tautology or ambiguity.
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 only guidance is 'Requires: Wallet must be initialized,' which sets a prerequisite but does not mention when to use this generic tool over the specialized `ordnet_domain_register_sns` or `ordnet_domain_register_opns` siblings. There are no exclusions or alternative scenarios described, leaving the selection to inference.
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 declare readOnlyHint=false and destructiveHint=true, so the write/destructive nature is covered. The description adds the return shape ({ txid, inscriptionId, domain }) but does not disclose further behavioral details like transaction costs or side effects. With annotations present, this is acceptable but not exemplary.
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 concise and well-structured with an Args list and Returns line. It is front-loaded with the purpose. The 'Quick' modifier and repetition of schema defaults are minor wastes, but the overall length is appropriate for a three-parameter tool.
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 simple registration tool with full schema coverage and annotations, the description covers the purpose, parameters, and return value. However, it lacks explicit usage guidance against siblings and contains the feePerByte default error, which prevents it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage with descriptions and constraints, so baseline is 3. However, the description contains an incorrect default for feePerByte (0.2 vs. 0.15 in the schema), which actively contradicts the schema and could mislead the agent. This reduces the score below baseline.
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 'Quick registration of an OPNS domain', which uses a specific verb ('registration') and resource ('OPNS domain'). This clearly distinguishes it from sibling tools like ordnet_domain_register_sns and generic ordnet_domain_register.
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 implies usage by naming 'OPNS domain', but it does not explicitly state when to use this tool versus alternatives (e.g., SNS registration). There is no exclusion or mention of other domain types, so guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's return fields (iv, salt) imply randomness, contradicting the annotation idempotentHint=true. Since AES-GCM typically requires unique IVs and salts, this is a significant behavioral inconsistency. Annotation Contradiction flagged.
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?
Concise, front-loaded with the core purpose, then args and return format in a clean list. No wasted words.
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?
No output schema exists, so the description explains the return format. It also covers companion decryption tool and password strength. Missing error cases/security caveats, but adequate for a simple encryption utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (wif and password already explained). The description repeats the same info and adds no deeper meaning beyond specifying min 12 chars, which matches minLength. Baseline 3 is appropriate.
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 'Encrypt a WIF private key with AES-256-GCM' – a specific verb, resource, and algorithm. It clearly distinguishes the tool from wallet management and inscribing 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?
Provides explicit context: 'Use this to create an encrypted wallet that can be stored safely' and names the companion decryption tool 'ordnet_wallet_init'. Does not list exclusions but sufficiently conveys when to use.
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 description adds the return shape ('{ contentTypes: [...] }') and the scope ('all supported content types') beyond the annotations' safety profile. This gives the agent a clear expectation of the output.
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 two short sentences, front-loaded with the purpose, and the return format is clearly separated. No filler words.
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 parameterless read-only tool, the description adequately states the purpose and return structure. However, it does not enumerate the possible content type values or explain any fallback behavior, which is a minor gap given the absence of an 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?
There are zero parameters, and the description correctly implies none are needed. The schema already covers the empty parameter set, so no additional parameter explanation is required.
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 ('Get list') and the resource ('all supported content types for inscriptions'), making the tool's purpose unambiguous. However, it does not explicitly differentiate from siblings, though the resource is unique.
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 no guidance on when to use this tool versus alternatives, no prerequisites, or exclusions. It simply states the action.
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 indicate this is destructive (destructiveHint=true, readOnlyHint=false), but the description adds behavioral context by specifying 'broadcast' (confirming irreversible on-chain action) and detailing the return structure { txid, inscriptionId, viewUrl }. This enriches the agent's understanding beyond the annotation flags.
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 action, followed by a simple argument list and return format. It wastes no words, though the argument list largely repeats schema content, which slightly reduces its added value.
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 tool has no output schema, so the described return format is helpful. It also mentions 'one step' to differentiate from prepare/broadcast siblings. However, it omits practical context such as wallet requirements, fee behavior, or content type constraints (e.g., must be valid JSON). The fee default discrepancy also leaves the tool description incomplete relative to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does add the JSON qualifier for content, but it introduces a critical error: the described default for feePerByte is 0.2, while the schema clearly states default: 0.15. This contradiction can mislead the agent into using an incorrect fee, undermining the parameter semantics despite the schema's completeness.
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 tool's action: 'Create and broadcast a JSON inscription in one step.' This specific verb+resource formulation distinguishes it from sibling tools like ordnet_inscribe_prepare and ordnet_inscribe_broadcast, which split the process into separate steps.
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 phrase 'in one step' implies use when a combined create-and-broadcast operation is desired, but it does not explicitly mention alternatives or provide concrete when-to-use versus when-not-to-use guidance. With many sibling inscription tools (html, text, binary), the description could be clearer on when JSON is the appropriate content type.
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 provide destructiveHint=true and readOnlyHint=false, so the description does not need to restate safety. It adds 'broadcast' and the return format, which is useful, but it does not disclose irreversibility or the need for wallet funds beyond the feePerByte parameter. This is adequate but not richly contextual.
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 concise and well-structured with Args and Returns sections, front-loading the core purpose. It is somewhat repetitive with the schema and contains a factual error, but overall it is efficient and scannable.
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?
Given no output schema, the description usefully specifies the return shape (txid, inscriptionId, viewUrl). However, it omits prerequisites such as wallet initialization and funded UTXOs, and does not elaborate on the destructive nature beyond the annotation. This makes it incomplete but serviceable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. However, the description contains an incorrect default for feePerByte (states 0.2, schema says 0.15) and merely restates the content parameter without adding meaningful semantics. This inconsistency and lack of added value lower the score.
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 uses a specific verb 'Create and broadcast' and specifies the resource 'plain text inscription', clearly distinguishing it from other content-type tools (html, json, binary) and the split prepare/broadcast tools. The scope 'in one step' further clarifies its combined nature.
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 phrase 'in one step' implies this tool is a combined alternative to ordnet_inscribe_prepare and ordnet_inscribe_broadcast. It gives clear context for when to use this tool (for plain text, single-step), but does not explicitly state when not to use it or name alternatives like the HTML/JSON variants.
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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the return fields (maxSatsPerTx, maxSatsPerSession, spentThisSession, broadcastCount), which is useful. However, it does not explain what 'session' means or when totals reset, leaving a minor gap. 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 extremely concise: one sentence and a return list. Every word earns its place, and the most important information is front-loaded (what it does) followed by the return contract.
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 no-parameter, read-only status tool, the description is complete enough. It states the purpose and lists the exact return fields. Given no output schema exists, the description fulfills that role. A minor ambiguity about the term 'session' prevents a perfect 5.
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?
The tool has zero parameters, and schema description coverage is 100% (trivially). Per the guidelines, 0 params yields a baseline of 4. There is nothing for the description to add about parameters, and it correctly omits any.
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 'Show the active spend policy and session totals' uses a specific verb ('Show') and clearly identifies the resource (spend policy and session totals). It distinguishes itself from sibling tools like ordnet_policy_set (which mutates policy) and ordnet_wallet_status (which shows wallet state).
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?
No explicit guidance on when to use this tool versus alternatives. It does not mention that ordnet_policy_set is for changing the policy, nor does it state that this is a read-only check before spending. The usage context is only implied by the tool name and description.
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, idempotentHint, and non-destructive, so the safety profile is clear. The description adds valuable context beyond annotations: the return structure (domains with name, owner, inscriptionId, count) and the prefix-based search behavior. This is useful but not excessive.
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 short and structured with Args and Returns sections, making it easy to scan. It includes all necessary details without fluff, though the Args section somewhat duplicates the schema descriptions. Overall, it is appropriately concise.
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 correctly explains the return format. It also covers the parameters and the domain-prefix search behavior. Missing details like result ordering, empty results, or explicitness about 'prefix' semantics are minor and do not hinder use.
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 coverage is 100%, and the description repeats the parameter descriptions without adding much new meaning. 'Query' and 'limit' are self-explanatory and already well-described in the schema. The description does not clarify format, validation, or behavior beyond schema defaults.
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 tool's purpose: to search for registered domains by name prefix. This is a specific verb (search) and resource (registered domains) and implicitly distinguishes from sibling tools like domain_check (availability) and domain_info (individual domain details).
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 implies usage context ('registered domains', 'by name prefix') but does not explicitly state when to use this tool over alternatives, nor does it mention when not to use it. There's no comparison to sibling domain tools, leaving the agent to infer the tool's 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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context such as the exact service fee breakdown (396 sats across 10 addresses), the miner fee floor, and the return object fields (estimatedTxSize, minerFee, serviceFee, totalCost, breakdown). This goes beyond the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-sentence purpose, a list of fee breakdowns, Args, and Returns. Although the fee breakdown is somewhat detailed, it is directly relevant to understanding the calculation. Every element serves a purpose, but the breakdown list could be more compact if needed. It is appropriately front-loaded.
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?
Even without an output schema, the description specifies the exact return fields (estimatedTxSize, minerFee, serviceFee, totalCost, breakdown), making the tool's behavior transparent. It also covers the fee structure and defaults. Given the simple two-parameter input and read-only nature, the description is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats the parameter names and adds 'default: 0.15 = 150 sats/KB, miner fee floor 200 sats' for feePerByte, which provides extra interpretive context not in the schema. contentSize is described similarly to the schema. Overall, the description adds marginal value but does not significantly exceed what the schema already provides.
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 'Calculate fee estimate for an inscription,' which clearly states the tool's function as a fee calculator using a specific verb and resource. This distinguishes it from sibling tools like ordnet_inscribe_prepare or ordnet_tx_simulate, which handle execution or simulation. The title reinforces the purpose.
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 implies usage—e.g., to estimate inscription fees before inscribing—by providing a fee breakdown and return structure, but it does not explicitly state when to use this tool versus alternatives like ordnet_tx_simulate or ordnet_price. There is no clear when-not or mention of alternative tools, so the 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=true and idempotentHint=true, establishing the safe read operation. The description adds value by listing the return fields (name, extension, owner, inscriptionId, genesisHeight, protocol), which is not available elsewhere since no output schema exists.
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 concise and well-structured, with a clear opening sentence followed by Args and Returns sections. Every line provides necessary information with no redundancy or 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 read-only tool with one parameter and no output schema, the description provides the return field list, making the output clear. It lacks explicit error handling or edge-case info, but given the low complexity and strong annotations, it is sufficiently 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?
The input schema fully describes the single parameter 'fullName' with pattern and example, so the description's 'Full domain name (e.g., "myname.sats")' adds no new meaning. With 100% schema coverage, the baseline of 3 applies.
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 'Get detailed information about a domain' with a specific verb and resource. It distinguishes from sibling tools like ordnet_domain_check and ordnet_domain_search by focusing on detailed info retrieval.
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 implies usage (when you need domain details) but does not explicitly mention alternatives or exclusions. Unlike the high-calibration example, it fails to name sibling tools or provide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds a partial return structure (inscriptionId, contentType, contentSize, owner, ...), which gives some behavioral insight beyond annotations. However, it does not specify error handling, availability of historical data, or other edge-case behavior, so it only partially augments the annotation-provided context.
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 extremely concise, with no filler words. It is structured into Args and Returns sections, making it easy to parse. Every sentence provides useful information and nothing is redundant or unnecessary.
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 tool with a single parameter and no output schema, the description provides a reasonable outline of the return payload. It lists key fields and uses '...' to indicate additional fields. It lacks explicit mention of error handling (e.g., non-existent inscription), but the overall context is adequate for an agent to select and invoke the tool correctly.
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 coverage is 100%: the input schema already contains the format and pattern for inscriptionId. The description repeats the format 'txid_outputIndex' but adds no new meaning beyond what the schema provides. Therefore, the description provides no additional parameter semantics, and the baseline for high schema coverage applies.
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 tool's function: 'Get detailed information about a specific inscription.' It uses a specific verb ('Get'), identifies the resource ('inscription'), and the qualifier 'specific' distinguishes it from sibling search tools like ordnet_search_inscriptions. The return field list further clarifies its purpose.
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 makes it clear this tool is for retrieving details of a single inscription when you already have an inscription ID. It does not explicitly mention alternatives or exclusions, but the phrase 'specific inscription' implies a different use case from searching or retrieving content URLs. This is clear context without exclusions.
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 destructiveHint:true and readOnlyHint:false. The description adds 'Requires: Wallet must be initialized' and specifies return fields (txid, inscriptionId, viewUrl). This provides useful behavioral context beyond the annotations without contradiction.
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 front-loaded with a clear purpose and uses a compact, structured format (Args, Returns, Requires). The second sentence is slightly redundant with the first, but overall it is concise and well-organized.
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 tool, the description provides the essential context: one-step operation, wallet prerequisite, and return value shape. It doesn't discuss fees beyond feePerByte or immutability, but these are adequately covered by annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100% (baseline 3), the description's stated default for feePerByte (0.2) directly contradicts the schema's default (0.15), which can mislead the agent. It adds little beyond the schema's own parameter descriptions and introduces an error.
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 it 'Create and broadcast an HTML inscription in one step' and identifies it as a convenience tool that combines preparing and broadcasting. This distinguishes it from sibling tools like ordnet_inscribe_prepare, ordnet_inscribe_broadcast, and JSON/text inscription variants.
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 explains this is a one-step convenience tool for HTML inscriptions, implying it is the right choice when you want to skip the staged prepare/broadcast flow. It doesn't explicitly mention alternatives, but the context is clear enough for selection.
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?
With all annotations set to false, the description carries the burden of disclosure. It transparently states the transaction is signed but not broadcast, and specifies the return fields and the prerequisite that the wallet must be initialized. It does not contradict annotations and adds useful behavioral detail, though it does not go into potential side effects like UTXO selection.
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 well-structured: a clear opening sentence, followed by behavior and return info, then Args/Returns/Requires sections. However, the Args section largely duplicates the schema and contains the incorrect fee default, so it is not perfectly concise. It remains appropriately sized and front-loaded.
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 tool is moderately complex and has no output schema, but the description covers the return structure (rawHex, txid, feeEstimate, inscriptionId) and the prerequisite (wallet initialization). It also makes clear the transaction is not broadcast. This is a complete enough description for an agent to understand what the tool does and what to expect, though it could mention that broadcasting is done separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, so the baseline is 3. The description adds some useful context (content examples, MIME type default), but it incorrectly states the default for feePerByte as 0.2 while the schema specifies 0.15. This contradiction actively misleads the agent, so the score is lowered to 2.
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 a specific verb and resource: 'Prepare an inscription transaction without broadcasting.' It differentiates from sibling tools like ordnet_inscribe_broadcast by explicitly noting it does not broadcast, and provides a concrete outcome (signed transaction, raw hex, fee breakdown). This is a strong, unambiguous purpose.
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 usage context: 'for review before broadcasting' and 'without broadcasting,' implying a pre-broadcast step. It does not explicitly name alternatives like ordnet_inscribe_broadcast, but the exclusion of broadcasting is explicit. Since it lacks explicit alternative references, it earns a 4 rather than a 5.
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 indicate readOnly=false and destructiveHint=true, but the description adds valuable behavior: fee structure (miner-only, min 200 sats), safety policy enforcement, and the guarantee that 1-sat ordinal UTXOs are never used as funding. This goes beyond the structured annotations without contradicting them. It doesn't cover all edge cases (e.g., error handling), but given annotation coverage, a 4 is appropriate.
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 well-structured: a clear lead sentence, a focused paragraph on fees and safety, then concise Args/Returns sections. It is slightly redundant with the schema for parameters, but overall it is compact and front-loaded. Every section serves a purpose, earning a 4.
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 no output schema exists, the description compensates by explicitly listing the return object { txid, satoshis, minerFee, change, transactionUrl }. It also covers prerequisites (initialized wallet), fee behavior, safety constraints, and optional OP_RETURN usage. It does not mention error cases or policy-check failure outcomes, but for a transaction tool it is fairly 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 coverage is 100%—all three parameters have descriptions in the input schema. The description's Args section largely repeats the schema (to, satoshis, opReturn) with no additional semantic depth. The OP_RETURN mention as a 'payment reference' is already present in the schema property description, so the description adds minimal new meaning.
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 'Send a plain BSV payment (P2PKH) from the initialized wallet,' which is a specific verb+resource statement. It further distinguishes itself by calling it 'THE core tool for agent payments' and emphasizing 'plain' vs. ordinal-related transfers, setting it apart from sibling tools like ordnet_transfer and the x402 flow.
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 context: it is the primary tool for agent micropayments, explicitly noting 'miner fee only (0.15 sat/byte, min 200 sats), NO service fees' and optional OP_RETURN for references. It also mentions the wallet must be initialized and that spend policy is enforced. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
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=true, idempotentHint=true, and destructiveHint=false, establishing a safe, non-mutating operation. The description adds the return shape { valid, address } and clarifies that only format is validated, which is useful behavioral context beyond the annotations. No contradictions.
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 concise and well-structured with a leading one-sentence summary followed by Args/Returns sections. Every sentence earns its place, and there is no redundant 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-parameter validation tool with rich annotations and no output schema, the description is complete. It states the purpose, documents the return object, and clarifies the scope ('format'), covering all essential aspects without needing additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'address' described as 'BSV address to validate' and length constraints 25-35. The description repeats this without adding additional semantic detail, such as examples, accepted character sets, or how the boolean result is determined. Baseline 3 is appropriate.
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 tool validates a BSV address format, using a specific verb ('Validate') and resource ('BSV address'). This distinguishes it from sibling tools like domain_check or security_validate_password, and the scope ('format') is explicit.
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 implies the tool is used to check the validity of a BSV address format, but it does not explicitly state when to use it instead of alternatives, nor does it mention exclusions such as not checking whether the address exists on-chain. The usage context is clear but left implicit.
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 return format ({ utxos, count }) and default limit behavior, plus optional address semantics. This is helpful context beyond annotations, though pagination and ordering are not covered.
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 concise and well-structured with an Args/Returns format. Every sentence adds value; no fluff.
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 2 optional parameters, the description thoroughly covers purpose, arguments, and return values. It is complete enough for an agent to invoke correctly.
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 coverage is 100%, so parameters are fully documented. The description repeats the same parameter details from the schema without adding new information, so the baseline 3 applies.
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 'Get unspent transaction outputs (UTXOs) for an address' with a specific verb and resource. It differentiates from sibling wallet tools like wallet_balance and wallet_status by focusing on UTXOs, and notes optional address behavior.
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 context (get UTXOs for an address, optional address) but does not explicitly name alternatives or exclusion criteria. Sibling tools like wallet_balance and wallet_status are not referenced, so an agent might not know when to prefer this over them.
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?
Beyond the annotations (idempotent, non-destructive, not read-only), the description adds behavioral detail: the index seeds the address immediately via WhatsOnChain as an outpoint hint, verifies UTXOs with ORDnet's own node, and tracks in real time via the tip-follower. This gives useful transparency about the internal mechanism without contradicting 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 well-structured: a clear opening sentence, a concise explanatory paragraph about the seeding and tracking mechanism, followed by structured Args and Returns sections. Every sentence adds value and it is front-loaded with the primary purpose.
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 two parameters and no output schema, the description covers purpose, mechanism, usage context, parameters, and return type. The return statement ('Watchlist registration result from the index') is vague, but given the tool's simplicity and the provided annotations, the overall context is sufficiently 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 100%, so the baseline is 3. The description's Args section essentially mirrors the schema (address is 'BSV address to watch', label with default 'mcp'). It adds no significant semantic meaning beyond what the schema already provides.
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 'Register a BSV address in ORDnet's own UTXO index watchlist' – a specific verb+resource statement that clearly defines the tool's purpose. It distinguishes from siblings by focusing on watchlist registration for instant first queries, which no other sibling tool addresses.
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 explains when to use this tool versus relying on auto-registration: 'this tool lets an agent pre-register addresses so that first query is instant.' This provides clear usage context, though it does not explicitly name alternative tools or state 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?
Annotations already convey that this is a non-read-only, open-world operation. The description adds useful behavioral context: the first-is-first rule, the fact that returning a prepared inscription does not guarantee ownership, and the text/plain format following the bitmap convention. This goes beyond what annotations alone 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 concise and front-loaded with the primary action. The note about first-is-first is essential and clearly separated. No redundant sentences; every part earns its place.
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 properly states the return value (a prepared inscription) and directs to the broadcast sibling. It covers the key workflow and the main caveat (ownership). While it doesn't detail error cases, the combination of annotations and description is sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description repeats the same parameter details (tile range, feePerByte default). It adds a little context by explaining the tile maps to the 1M-tile grid, but the schema already documents the parameters adequately. Overall, the description adds minimal meaning beyond 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 tool's purpose: claim a BSVmap tile by inscribing a text/plain tile name. It specifies the exact resource (BSVmap tile) and the convention, and it distinguishes from sibling inscription tools by focusing on the BSVmap claim process.
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 note provides concrete usage guidance: check if the tile is already claimed on bsvmap.io first, because first-is-first. It also indicates the follow-up action (broadcast with ordnet_inscribe_broadcast). While it doesn't explicitly name alternative tools, the context makes the intended workflow 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 indicate read-only, idempotent, and non-destructive behavior, and the description adds valuable context by explaining the meaning of the three tiers and the return fields. There is no contradiction with annotations, and the description enriches the agent's understanding beyond the structured metadata.
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 concise and well-organized: starts with the core purpose, then lists tiers in a clear hierarchy, and finishes with the return object structure. Each sentence earns its place 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?
For a simple zero-parameter read-only tool, the description covers the essential details: tier semantics and return fields. The 'recommendation' field lacks elaboration, but overall the description is sufficiently complete given the tool's simplicity.
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?
This tool has zero parameters, and schema coverage is 100%. The description appropriately omits parameter details, and the zero-parameter baseline of 4 applies here.
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 tool's function with a specific verb and resource: 'Check the current wallet security tier.' It distinguishes itself from sibling tools like ordnet_wallet_status by focusing on security tier specifically and even lists the tier hierarchy for clarity.
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 implies use for checking the wallet's security tier but does not explicitly state when to use it versus alternatives such as ordnet_wallet_status. It offers no exclusions or context about when to prefer this tool, making the guidance implicit rather than explicit.
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, idempotentHint, and destructiveHint. The description adds valuable context that no wallet is required (auth-free verification) and specifies the return shape { valid: boolean }, which is especially useful since there is no output schema. 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 highly concise and well-structured: a one-line definition, a short wallet-independence note, a single usage sentence, a bulleted Args list, and a Returns line. Every sentence carries useful information with no repetition or 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 verification tool, the description covers purpose, usage context, parameter semantics (via schema), and return value. It does not mention error cases or encoding specifics, and the relationship to ordnet_sign_message is implicit rather than explicit, but it is sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – each parameter already has a descriptive text. The Args section essentially restates the schema without adding new semantics or edge-case guidance. The only minor addition is reinforcing that the signature comes from ordnet_sign_message, which the schema already states.
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 'Verify a signature against a message and public key (BRC-100 verifySignature)', which clearly specifies the verb (Verify), the resource (message signature), and the algorithm/standard. This distinguishes it from siblings like ordnet_sign_message, which is its counterpart.
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 context for when to use the tool: 'Does NOT require a wallet — anyone can verify' and 'Use this to check that a counterparty's message... really came from the holder of a given public key.' It does not explicitly name alternative tools or state when not to use it, but the use case is well-defined.
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, idempotentHint, and destructiveHint, so the tool is known to be safe. The description adds useful behavioral context by noting that address and balance are conditional on initialization, which clarifies the response shape 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?
The description is extremely concise, with two short sentences and a well-formatted return type. It front-loads the core purpose and includes no filler, making it easy to parse quickly.
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 tool's simplicity (no parameters, no output schema), the description adequately covers its purpose and return values. The return type is explicitly documented, which is essential since there is no output schema. It does not elaborate on edge cases, but none are critical for this read-only status check.
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?
The tool has zero parameters, so the schema provides complete coverage (100%). The description does not need to elaborate on parameters. Baseline of 4 is appropriate given no parameters exist.
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 tool checks wallet initialization status and balance, with a specific verb ('Check') and resource ('wallet'). It also specifies the return values (address and balance if initialized), which distinguishes it from sibling tools like ordnet_wallet_balance that likely only report balance.
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 implies usage for checking wallet status and balance but does not explicitly say when to use this tool instead of alternatives such as ordnet_wallet_balance or ordnet_wallet_utxos. There is no mention of exclusions or alternative tools, so the context 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 cover read-only, idempotent, non-destructive traits. The description adds value by specifying the return shape ({ available: boolean, owner?, inscriptionId? }), which is not in the annotations or an output schema. It does not describe error conditions, but for a read-only check this is acceptable.
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 purpose, followed by concise Args and Returns sections. Every sentence serves a purpose; no filler or unnecessary verbosity.
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 simple two-parameter read-only tool, high schema coverage, and complete annotations, the description adequately covers what the tool does, its inputs, and output structure. With no output schema, the returns section is essential and provided clearly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both name and extension are fully described in the schema. The description's Args section essentially repeats the schema descriptions without adding new meaning (e.g., extension default is already in schema). Hence no added value beyond 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 function with a specific verb and resource: 'Check if a domain name is available for registration.' It distinguishes from siblings like ordnet_domain_info and ordnet_domain_search by focusing on availability for registration, not general info or search.
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 implies usage context—checking availability before registration—but does not explicitly mention alternatives or when not to use the tool. It gives clear context but lacks explicit exclusions or references to 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds value by specifying the exact return fields (inscriptionId, contentUrl, viewUrl, transactionUrl), which goes beyond the annotations and clarifies the tool's output 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 extremely concise, with a clear one-sentence purpose followed by Args and Returns sections. Every line adds necessary information, and it is well-structured for fast parsing by an AI agent.
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 one-parameter getter tool, the description is complete: it explains the purpose, lists the parameter, and provides the return structure (since no output schema exists). Combined with the strong annotations, the agent has everything needed to invoke it correctly.
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 provides full coverage (100%) for the single parameter, including its format (txid_outputIndex). The description only repeats 'Inscription ID' without adding any new semantic detail, so it does not meaningfully enhance 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 'Get the URL to view inscription content', using a specific verb ('get') and resource ('URL to view inscription content'). It distinguishes itself from siblings like ordnet_get_inscription by focusing on URLs rather than general inscription data.
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 makes the tool's purpose clear: it returns URLs for viewing inscription content. However, it does not explicitly mention when not to use it or direct users to alternatives, such as ordnet_get_inscription for full metadata. This is a clear context but lacks explicit exclusions.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it returns server version, capabilities, and fee information, which is helpful but does not disclose additional behavioral traits like auth needs or rate limits. This is minimal added 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 two concise sentences with no redundancy. The first sentence states the action and resource, and the second lists the return items. It is well-structured and front-loaded, earning a perfect score.
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 low complexity (no parameters) and rich annotations, the description is sufficiently complete. It names the return contents (version, capabilities, fee info), which is adequate for a simple server info tool without an 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?
The tool has zero parameters, and schema coverage is 100% (empty schema). The description does not need to explain parameters. The baseline for 0 parameters is 4, and no further semantic clarification is required.
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 action 'Get information' and the resource 'ORDnet MCP server'. It is specific and distinct from sibling tools that focus on wallet, domain, or inscription operations, making its purpose unambiguous.
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 context that this is a server-level info query with no parameters, implying a diagnostic or introductory use. However, it does not explicitly mention when to use it versus alternatives or when not to use it, so it falls short of a 5.
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 provide the safety profile (readOnlyHint=false, destructiveHint=false). The description adds valuable behavior beyond that: 'Bytes are inscribed untouched' indicates no transformation of the binary data. It also discloses that this is a preparation step by saying 'Returns prepared inscription; broadcast with ordnet_inscribe_broadcast,' which clarifies the non-final nature of the action. Slightly more detail (e.g., side effects or permission requirements) could push it higher, but this is solid with annotation support.
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 well-structured: a clear opening sentence, a behavioral note, a supported-types list, and an Args block. It is not excessively long, but the Args block somewhat duplicates the schema and could be trimmed without loss. However, every sentence carries useful information, and the front-loading of the core purpose is effective.
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 steps up by stating the return type ('Returns prepared inscription') and connecting the workflow with ordnet_inscribe_broadcast. It also covers supported MIME types and parameter constraints. It lacks details about limits (e.g., maximum file size) or edge cases, but given the tool's simplicity and rich sibling context, this is adequate and only slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's Args section largely repeats the schema: contentBase64, contentType, feePerByte. It does add 'default 0.15' for feePerByte and reinforces that contentBase64 is base64-encoded, but these are already present in the schema. No additional parameter semantics beyond the schema are provided, so it stays at the baseline.
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 a specific verb+resource: 'Prepare an inscription for BINARY content (images, audio, video, PDF) from base64.' It clearly distinguishes itself from sibling tools by explicitly naming ordnet_inscribe_prepare and saying to use this for anything that is not text. The supported MIME type list further scopes the tool's purpose.
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?
Explicit usage guidance is provided: 'use this instead of ordnet_inscribe_prepare for anything that is not text.' It also lists supported content types (e.g., image/png, application/pdf) and directs the user to the next step in the workflow: 'broadcast with ordnet_inscribe_broadcast.' This gives clear when-to-use and workflow context.
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 the tool read-only, idempotent, and non-destructive. The description adds behavioral context by naming the proxy and detailing the return structure ({ bsv: { usd, eur, ... }, satsPerUsd }). No contradictions, but it could mention potential latency or external dependency.
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, with a clear one-line purpose, a usage hint, and an Args/Returns section. Every sentence adds value and it is front-loaded.
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 a simple single-parameter, read-only tool, the description covers purpose, usage, parameter, and return format. The absence of an output schema is compensated by the explicit Returns section, making it fully self-contained.
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 already fully describes the 'currencies' parameter with the same default and format. The description's Args section merely repeats this, adding no new semantic information beyond the schema, so a baseline score of 3 is appropriate.
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 tool gets the current BSV price in fiat, specifying it uses ORDnet's own CoinGecko proxy. This distinguishes it from sibling tools like ordnet_fee_estimate or wallet-related 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 provides a clear usage context: 'Lets an agent convert satoshis to USD/EUR before spending.' However, it does not explicitly list alternatives or when not to use, so it falls short of a 5.
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=true and idempotentHint=true, so safety is established. The description adds the exact validation criteria (12+ chars, upper/lowercase, number, special character) and the return shape ({ valid, errors }), providing useful context 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?
The description is well-structured with a clear opening sentence, a concise bulleted list of requirements, and explicit Args/Returns sections. It avoids unnecessary filler while conveying all essential details.
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 single-parameter tool, the description is fully complete: it explains the validation rules, the exact input, and the output format. There is no output schema, but the return object (valid, errors) is documented, eliminating ambiguity.
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 coverage is 100%: the parameter 'password' is described as 'Password to validate' in both the schema and the description. The description adds no new meaning, so the baseline of 3 applies.
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 'Check if a password meets security requirements', which clearly identifies the verb (validate/check) and resource (password strength). It is distinct from sibling tools like ordnet_validate_address or ordnet_security_tier by explicitly focusing on password validation.
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 clearly implies when to use it—whenever a password needs strength validation. It does not explicitly state exclusions or alternatives, but the context is unambiguous and no sibling tool overlaps with this function.
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 include readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond these: 'The private key never leaves the server' (security guarantee) and 'Requires an initialized wallet' (precondition). These details materially help the agent reason about invocation, so the description earns credit beyond the annotation baseline.
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 well-structured and front-loaded with the core purpose, followed by use cases, a security note, a prerequisite, and a compact Args/Returns listing. Every sentence contributes meaningful information without redundancy or fluff. It is concise yet complete for a single-parameter tool.
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 parameter and no output schema, the description provides an unusually complete picture: purpose, use cases, security guarantee, prerequisites, parameter meaning, and return shape. The agent knows exactly what to expect and how to use it, and the description also contextualizes the tool among many wallet-related siblings. No significant gaps remain.
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 coverage is 100%, and the schema's property description ('Message to sign with the wallet key') already conveys the semantic meaning. The description's 'Args: - message (string): the message to sign' essentially restates the schema without adding new information about format, encoding, or constraints. Per the rubric, baseline 3 is appropriate when the schema does the heavy lifting.
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 'Sign an arbitrary message with the wallet's private key,' which is a specific verb+resource statement. The addition of the protocol identifier '(BRC-100 createSignature)' further pins down the exact operation. It is clearly distinguished from sibling tools like ordnet_verify_message by the explicit 'sign' action.
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 explicit use cases: 'prove control of the identity key, authenticate to a service, or sign an x402 payment authorization off-chain.' It also states a prerequisite ('Requires an initialized wallet'), which helps the agent know when the tool is applicable. It does not include explicit 'when not to use' or alternative tool suggestions, but the use-case list is sufficiently contextual.
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?
Beyond the read-only and idempotent annotations, the description adds the default behavior (uses wallet address) and the return shape (confirmed, unconfirmed, total). This gives useful context not present in 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 concise and front-loaded with the main action. It uses a clear Args/Returns structure with no unnecessary words, making it easy to parse.
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 only one optional parameter and no output schema, the description fully covers the tool's behavior, default, and return format. It is complete for an agent to invoke correctly.
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 already fully describes the optional address parameter with the same information as the description (default to wallet). The description adds no additional semantic value beyond 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 tool gets a BSV balance for any address, using a specific verb and resource. It distinguishes from sibling tools like ordnet_wallet_utxos by focusing on balance rather than UTXOs.
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 context: it works for any address and defaults to the wallet address when omitted. It does not explicitly mention alternatives or exclusions, but the usage scenario is evident.
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 idempotentHint=true and non-destructive, and the description adds valuable security context: 'WIF is held in memory only, not persisted.' It also discloses fee details and that this is non-production (via the init_env reference). 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?
Well-structured with sections (intro, use cases, security, args, returns, example). It is somewhat verbose with fee details, but each section serves a purpose and the key information is front-loaded. Not wasteful overall.
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 tool is relatively simple with one parameter and no output schema. The description covers return value, example, security, and usage context. It lacks error-handling details, but that is not essential given the schema and annotations. Complete enough for a single-purpose init tool.
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 coverage is 100% with wif described in the schema (pattern, minLength, maxLength). The description repeats the format and adds an example, but does not significantly augment the schema's meaning. Baseline 3 is appropriate.
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 'Initialize wallet from WIF private key for blockchain operations', using a specific verb and resource. It differentiates from siblings by mentioning 'Use ordnet_wallet_init_env for production' and positioning itself as the initial step before inscription creation.
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 says 'This is the first step before creating inscriptions' and lists concrete use cases (creating/signing, paying fees, receiving change). It also provides an explicit alternative: 'Use ordnet_wallet_init_env for production', giving clear when-to-use guidance.
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 indicate idempotentHint=true and destructiveHint=false. The description adds context about the security tier and reading from an environment variable, but does not disclose potential side effects like whether an existing wallet is overwritten or if state is persisted. With annotations covering the safety profile, this is acceptable but not rich.
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: a summary sentence, a security note, ARGS, RETURNS, and an example. Every part earns its place without unnecessary verbosity. Front-loaded with the primary purpose.
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 tool with one optional parameter and no output schema, the description fully covers what it does, how it works, the parameter, the return shape, and a usage example. It is complete enough for an agent to select and invoke correctly.
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 coverage is 100% with a clear description of the sole parameter. The description repeats the parameter and default but does not add significant meaning beyond the schema. An example shows calling with empty object, but the semantic value of the parameter is fully captured 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 it initializes a wallet from an environment variable, using a specific verb and resource. It distinguishes itself from sibling tools like ordnet_wallet_init by emphasizing the security-enhanced method of reading the WIF from an env var rather than passing it directly.
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 recommends it for production use and highlights the security tier, implying when to use this over direct WIF passing. The phrase 'instead of passing it directly' effectively contrasts with the alternative initialization method, providing clear 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds behavioral context beyond that: it specifically explains the mechanism (reads the HTTP 402 response) and what fields are returned. This is useful and consistent with the annotations, with no contradiction.
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 well-structured and concise: a single purpose sentence, one usage sentence, then clear Args and Returns sections. Every sentence earns its place, and the formatting is clean and scannable.
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 two-parameter tool, the description is fully complete. It explains what the tool does, when to use it, the parameters, and the return shape. The strong annotations cover safety, so no additional behavioral disclosure is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'url' and 'method' parameters already have meaningful schema descriptions (URL of the resource, HTTP method with enum/default). The description's Args section essentially repeats this information without adding new semantics. Baseline 3 is appropriate because the schema does the heavy lifting.
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 a specific verb+resource: 'Inspect an x402-paywalled URL WITHOUT paying' and clearly states it returns price, payTo address, and payment requirements from the HTTP 402 response. This distinguishes it from the sibling ordnet_x402_fetch, which likely fetches content after payment.
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 context: 'Use this to check costs before committing.' It implies using this before actually paying/fetching, and notes it's free and read-only. However, it doesn't explicitly name alternatives (like ordnet_x402_fetch) or state when not to use this tool, so it falls just short of 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?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds substantial behavioral context: determinism per invoice, on-chain unlinkability, independent computability by payer/payee, and the prerequisite of an initialized wallet. It also states the return structure (address, publicKey, invoiceNumber), which is not covered by annotations or an output 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 well-structured and appropriately sized: a single-sentence summary, a short paragraph of behavioral context, a prerequisite note, and clearly labeled Args/Returns sections. Every sentence adds information; there is no fluff or repetition. The most important facts are front-loaded.
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-parameter tool with no output schema, the description covers all necessary aspects: purpose, key behavioral traits, prerequisite, the input parameter, and the return shape. It also situates the tool within the x402 payment flow, making its use case clear. There is no obvious missing 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?
The input schema already documents the single parameter (invoice number) with a good description ('Invoice/reference string; deterministically derives a unique payment address'). The description's Args section merely restates 'invoice/reference string' without additional parameter-level detail. The prose adds context about behavior, but not about the parameter's format or constraints beyond the schema. Thus the description adds no significant value over the schema's parameter documentation.
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 a specific verb ('Derive') and resource ('unique, deterministic payment address'), clearly differentiating it from sibling tools. It also names the standard (BRC-42/29) and explains the core use case (x402 payment flows), leaving 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it explains the deterministic relationship between invoice and address, the unlinkability property, and that a wallet must be initialized. It does not explicitly state 'use this instead of X' or enumerate exclusions, but the context is specific enough that an agent would know when to invoke it. The lack of explicit alternative comparison is the only gap, matching the 'clear context, no exclusions' level.
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, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: the initialized-wallet prerequisite and the purpose of the returned public key (signature verification, address confirmation). No contradictions.
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 appropriately concise: the first sentence states the core function, the second adds essential context about on-chain identity and signature verification, and the final sentence gives the return shape. Every sentence earns its place without redundancy.
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 zero-parameter, read-only tool with rich annotations and no output schema, the description is complete: it explains what the tool returns, why the returned data matters, and the prerequisite (initialized wallet). Missing error handling details are not critical for this simple getter.
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?
This tool takes zero parameters, so schema coverage is 100% and the description is not responsible for parameter documentation. The Description adds value by specifying the exact return shape ({ publicKey, address }), which is not covered by the input schema or an output 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 opens with a clear, specific verb ('Return') and resource ('the wallet's BRC-100 identity: its public key and address'). This immediately distinguishes it from sibling wallet tools like ordnet_wallet_status, ordnet_wallet_balance, and ordnet_wallet_utxos, which focus on other aspects of the wallet.
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 states a clear precondition ('Requires an initialized wallet') and explains the practical use case: counterparties can use the public key to verify signatures and confirm address control. While it doesn't explicitly exclude alternatives, the context strongly implies when this tool is appropriate.
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?
Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral context: every UTXO is individually verified by ORDnet's own BSV node, and WhatsOnChain is only a connectivity fallback. It also lists the exact return fields, which is useful since no output schema is provided.
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 concise and well-structured: a one-line purpose, two sentences of context, and a return field list. Every sentence adds value, and the main verb is front-loaded.
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 zero-parameter health-check tool, the description is complete. It explains what the tool does, why the index matters, and what it returns. The lack of an output schema is fully compensated by the explicit return field enumeration.
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?
The tool has zero parameters, so the description does not need to explain parameter usage. Per rubric, the baseline for 0 params is 4, and the description handles this perfectly by not wasting space on parameter details.
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 tool 'checks the health and sync status' of ORDnet's own address/UTXO index, using a specific verb and resource. It distinguishes itself from sibling tools like ordnet_wallet_status by focusing on the UTXO index, not the wallet.
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 provides clear context by describing this index as the PRIMARY source for balance and UTXO lookups since v2.5, implying it should be used to verify index health before relying on balance data. However, it does not explicitly name alternative tools or state 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?
Annotations already convey destructiveness, but the description adds critical context: 'IRREVERSIBLE' and 'permanently recorded on the blockchain,' explaining the consequence beyond a simple destructive hint. This adds meaningful behavioral insight.
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: a one-sentence purpose, a warning, args, and returns. Every element serves a purpose with no redundancy, and key information is front-loaded.
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 simple nature of a broadcast tool, the description covers all necessary aspects: purpose, irreversibility, parameter source, and return value shape. The absence of an output schema is compensated by the explicit return field list.
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 coverage is 100%, but the description adds value by specifying the rawHex source: 'Raw transaction hex from ordnet_inscribe_prepare.' This clarifies provenance and prerequisite, enhancing the schema's basic description.
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 tool's function: 'Broadcast a prepared inscription transaction to the BSV network.' This uses a specific verb ('broadcast') and resource ('prepared inscription transaction'), distinguishing it from sibling tools like ordnet_inscribe_prepare.
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 implies the usage context by specifying 'prepared' and referencing ordnet_inscribe_prepare for the rawHex, indicating this should be used after preparation. However, it doesn't explicitly state when not to use it or name alternatives, though few alternatives exist for broadcasting.
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 annotations that mark this as destructive, the description explains the 1SatOrdinals transaction construction, the unspent verification via ORDnet's own node, and the miner-fee-only policy. This adds significant operational context not visible in 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-organized: a clear first sentence, a brief technical semantics paragraph, and explicit Args/Returns sections. No unnecessary text; each part earns its place.
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 transfer tool with three required parameters and no output schema, the description supplies the return shape, construction semantics, and verification behavior. This gives an agent enough to invoke the tool confidently.
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 coverage is 100%, so all parameters are already described in the schema. The Args section repeats the schema descriptions without adding substantial new meaning. The 'usually 0' note for inscriptionVout is also present in the schema, so the description adds little beyond 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 opening line identifies a specific action ('Transfer') and a specific resource ('an inscription'), and enumerates the inscription types. This differentiates it from sibling tools like ordnet_send, ordnet_domain_register, etc.
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 clearly implies usage for transferring inscriptions, listing the inscription types. It doesn't explicitly name alternatives or exclusions, but the context is clear enough to distinguish from generic send 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, idempotentHint, and non-destructive, so the description doesn't need to restate that. It adds useful context about safety warnings (e.g., 1-satoshi outputs likely to be ordinals) and the fact that it uses ORDnet's own node, enhancing understanding 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 concise, front-loaded with a clear purpose, and uses a structured Args/Returns format. It includes necessary guidance and return shape without any wasteful text.
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 the lack of an output schema, the description explicitly lists the return fields (txid, sizeBytes, outputCount, totalOutputSats, outputs, warnings), covering the key information for use. With annotations ensuring safety and a single well-described parameter, the description is sufficient.
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 single parameter rawHex is fully described in the schema with details about hex format and dry-run behavior. The description's Args section merely repeats this, adding no new semantic meaning, so baseline 3 is appropriate.
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 tool decodes and inspects a raw transaction without broadcasting it, using a specific verb and resource. It distinguishes itself from sibling broadcast tools by framing it as a dry-run simulation before ordnet_inscribe_broadcast.
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 instructs to use this tool before ordnet_inscribe_broadcast to verify transaction behavior, providing a clear context. It does not detail when-not, but the contrast with broadcasting makes the usage boundary obvious.
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 readOnly/idempotent/non-destructive, and the description adds context about the data source (ORDnet's own node), polling behavior, and return fields. This goes beyond the annotations, though rate limits or error behavior are not mentioned.
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 concise, well-structured, and front-loaded. It includes a clear purpose line, usage guidance, args, and returns in a scannable format with no wasted words.
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 single-parameter tool with no output schema, the description provides all necessary context: what it does, when to use it, and what it returns. The return field list compensates for the missing output schema, making the behavior fully understandable.
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 coverage is 100% for the single parameter txid, and the description only restates the schema's 'Transaction ID' description without adding new meaning. Baseline 3 is appropriate since the schema does the heavy lifting.
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 tool checks transaction status and confirmations via ORDnet's own node, a specific verb and resource. It distinguishes from sibling tools by focusing on status checking, separate from send/transfer/broadcast operations.
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 says this is essential after ordnet_send, ordnet_inscribe_broadcast, and ordnet_transfer, and directs the user to poll it for confirmation. This provides clear when-to-use guidance and implies repeated use.
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 destructive and idempotent. The description adds valuable context by specifying that the wallet is cleared 'from memory' and documents the return value { cleared: true }, giving a clearer picture of the operation's scope and effect beyond the raw 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 extremely concise: two short sentences plus a return value block. It front-loads the primary action and avoids any filler, making it easy to parse and act on.
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 zero-parameter, simple tool, the description is fully complete. It states the action, when to use it, and the exact return value. No additional behavioral details are necessary given the low complexity.
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?
The tool accepts no parameters, so the input schema fully covers this dimension. With 100% schema coverage and no parameters, there is nothing for the description to add regarding parameter semantics, earning the baseline 4.
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 tool's function: 'Clear wallet from memory' with a specific verb and resource. It is distinct from sibling wallet tools like init, status, or balance, which all have different purposes.
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 phrase 'Use when done with operations' gives a clear, actionable context for when to call this tool. It does not explicitly mention alternatives or exclusions, but the usage context is unambiguous enough for an agent to decide.
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 destructiveHint annotations, the description adds crucial behavioral context: the WIF cannot be recovered if lost, emphasizing the need for secure storage. It also mentions the return of wif and address, which is important for the user.
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 concise with three sentences: the purpose, a warning, and the return value. Every sentence earns its place, and the most important information is front-loaded.
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 zero-parameter tool, the description is complete. It states the action, the output structure, and the critical security warning. No further clarification is needed given the lack of parameters and simple return.
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?
The tool has zero parameters, so the baseline is 4. The description correctly omits parameter details as there are none, and adds value by clarifying the output format.
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 tool generates a new random BSV wallet, using the specific verb 'Generate' with a resource. It distinguishes from sibling tools like wallet_init and wallet_status by focusing on the creation of a fresh wallet.
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 implies clear context for use: when a new random wallet is needed. It does not explicitly exclude alternatives like wallet_init or wallet_init_env, but the purpose is specific enough to guide selection.
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?
The description goes well beyond what annotations provide, explaining the fail-closed simulation behavior, the conservative upper-bound calculation including change sent back to the agent wallet, and the effect of removing limits. It also notes that broadcasts behave exactly as before when no limits are set, giving a complete safety profile.
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 well-organized, front-loaded with the core purpose, and uses concise paragraphs and a clear Args list. Every sentence adds value without redundancy, and the formatting makes it easy for an agent to parse quickly.
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 fully covers return behavior ('Returns the active policy after applying changes'), side effects (fail-closed broadcasting), and the semantics of each parameter. For a tool with three optional parameters and no nested objects, this is complete guidance.
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?
Input-schema coverage is 100% with detailed per-parameter descriptions, so baseline is 3. The tool description adds extra meaning by clarifying that limits apply to total output value including change, which is not explicitly in the schema's individual param descriptions. This additional context elevates the score.
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 uses a specific verb ('Configure') and clearly identifies the resource ('spend limits for this server session'), with the added context of being an 'agent safety layer.' It distinguishes itself from sibling ordnet_policy_status (view) by focusing on setting, not retrieving, policy.
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 explains when to use the tool: to impose spend limits that trigger fail-closed broadcast simulation. It clearly states the behavioral difference when no limits are set, providing strong contextual usage guidance. However, it does not explicitly mention alternatives like ordnet_policy_status for viewing current policy, so it misses a clear exclusion.
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 indicate a destructive, non-read-only, non-idempotent operation, but the description adds critical behavioral detail: the automatic payment from the wallet, the hard cap via maxSats, spend policy enforcement, network/scheme limitations, and the honest handling of unsupported networks. This goes well beyond the structured hints and gives the agent a clear safety model.
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 well-structured with a clear first sentence, a 'Safety' section for critical constraints, and a compact 'Args/Returns' listing. Every sentence earns its place, and the front-loaded purpose makes it easy to scan. It is detailed yet concise, with 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?
Given no output schema, the description provides a clear return structure ({ status, body, paid?, receipt? }) and covers the main behavioral outcomes (pay vs. no-pay, success conditions, unsupported scenarios). For a tool with payment side effects, this is a complete and usable description without needing extra context.
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 coverage is 100% and all parameters have descriptions, so the baseline is 3. The description adds value by framing maxSats as an 'agent-set budget' and emphasizing it is REQUIRED, which reinforces its role as a safety guard. It also clarifies the method default (GET) and the purpose of the URL, but these mostly mirror the schema, so a 4 is appropriate rather than 5.
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 a precise verb ('Consume') and a specific resource ('x402-paywalled resource'), then clearly outlines the one-call workflow: detect 402, pay, retry with proof, return resource + receipt. It also distinguishes itself from siblings like ordnet_x402_quote by emphasizing the auto-pay/consume action.
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 clearly states when to use the tool (to consume a paywalled resource in one call) and gives important constraints: maxSats is required, only 'exact' scheme on 'bsv' is supported, other networks are reported unsupported, and non-paywalled URLs are fetched without payment. However, it does not explicitly name the alternative for quote-only usage (ordnet_x402_quote), so it misses an explicit when-not-to-use reference.
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:

[![ORDnet-MCP-Server MCP server](https://glama.ai/mcp/servers/ORDNET/ORDnet-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/ORDNET/ORDnet-MCP-Server)

Score Badge

Copy to your README.md:

[![ORDnet-MCP-Server MCP server](https://glama.ai/mcp/servers/ORDNET/ORDnet-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/ORDNET/ORDnet-MCP-Server)

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/ORDNET/ORDnet-MCP-Server'

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