8DX MCP Server

Official

by 8DX-io

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Most tools have clearly distinct purposes, but `get_quote` and `preview_market_swap` overlap significantly since both return quote data, with the latter adding metadata. This could cause an agent to select the wrong one. All other tools such as wallet session management, limit orders, and WalletConnect operations are clearly separated.
Naming Consistency5/5
All 23 tools share the `eightdx_` prefix and follow a consistent snake_case verb_noun pattern, such as `get_quote`, `create_swap`, and `cancel_limit_order`. Even sub-groups like WalletConnect and local signer use consistent naming, making it easy to predict tool names.
Tool Count4/5
With 23 tools, the server is on the heavier side but the count is justified by the broad feature set covering swaps, limit orders, wallet management, WalletConnect, and local signing. No redundant tools seem present beyond the quote/preview pair, and each tool serves a distinct function within those domains.
Completeness4/5
The tool surface covers the full lifecycle for swaps (quote, preview, create, send), limit orders (create, cancel, query, history), and wallet sessions (login, logout, get). The inclusion of health check, explorer links, and permit data covers auxiliary needs, though a dedicated 'get supported chains' tool is missing.
Average 3.8/5 across 23 of 23 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that results are paginated, but does not disclose whether authentication is needed, if the operation is read-only, rate limits, or any side effects. This is a significant gap for a read operation with no annotation safety signals.
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 a single, well-structured sentence that front-loads the core action and resource. Every word earns its place, with no filler or repetition.
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?
Given the tool has 6 parameters, no annotations, and no output schema, the description is too minimal. It does not explain pagination mechanics (cursor vs offset), return format, any prerequisites, or clarify the difference from the sibling tool. The description is insufficient for reliable 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 description coverage is 100%, so the baseline is 3. The description does not add any extra parameter semantics beyond what the schema already documents; it only restates the 'maker' parameter as 'maker address,' which is redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets paginated limit-order history for a maker address, which is specific and actionable. However, it does not distinguish itself from the similarly named sibling tool eightdx_get_limit_orders_by_maker, so there is ambiguity about the exact difference.
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 guidance is provided on when to use this tool versus the closely related sibling eightdx_get_limit_orders_by_maker. The description simply states the function without giving context about appropriate use cases, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'This is a read-only operation,' which is a useful safety disclosure, but it does not explain what the quote represents, whether it executes anything, or any other important behavioral traits like quote validity, fees, or rate limits. The read-only claim adds minimal value beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, direct sentences with no filler. The core purpose is front-loaded and the read-only clarification follows. Every word earns its place.
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 is too sparse for a tool with 5 parameters, no output schema, and no annotations. It fails to describe the return value (quote details), the distinction or relationship between amountIn and amountInWei, or any dependencies such as wallet session. This leaves significant gaps for an agent to safely and correctly invoke the 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 descriptions cover 100% of parameters, providing clear explanations for blockchain, token addresses, and amount fields. The tool description itself adds no parameter information. Baseline 3 applies because the schema handles parameter semantics adequately.
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 verb 'Gets' and the resource '8DX swap quote' for a token pair and amount. It is specific and unambiguous, but it does not differentiate from sibling tools like eightdx_preview_market_swap, which may also provide quote-related functionality.
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 such as eightdx_preview_market_swap or eightdx_create_swap. It lacks any mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does convey that the operation is read-only via 'Reads' and hedges with 'if any', but it omits important traits such as whether it waits for a pending approval (despite the waitMs parameter) or what happens when no session exists. The schema parameter description adds some context, but the tool description itself lacks depth.
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 a single sentence that is direct and free of fluff. It front-loads the action and resource, making it immediately clear what the tool does. There is no wasted wording, so it earns full marks for conciseness.
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?
This is a simple tool with one optional parameter and no output schema. The description gives the basic purpose but does not explain return structure, error cases, or the effect of waitMs. Since there is no output schema to rely on, the description should provide more context about expected results and edge cases, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single waitMs parameter, so the baseline is 3 even without additional parameter info in the tool description. The description does not add any meaning beyond the schema, but it does not need to given the high schema coverage.
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 uses the specific verb 'Reads' and identifies the resource as 'the current WalletConnect session and connected wallet account'. This clearly states the tool's function. However, it does not explicitly distinguish itself from the sibling tool eightdx_get_wallet_session, which could be similar in scope, so it falls just short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It simply states what it does without mentioning any context, prerequisites, or exclusions. There is no mention of other tools or scenarios where this tool is preferred or not.
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?
With no annotations, the description carries full burden. It adds useful context by stating the session is non-custodial and never stores private keys, which is a significant behavioral guarantee. However, it does not disclose side effects like overwriting existing sessions, whether validation occurs, or what the response indicates.
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, front-loaded with the primary action and followed by a key security note. Every word earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple storage tool with no output schema, the description covers purpose and a critical constraint (no private keys). However, it omits return behavior, prerequisites, and any side effects, leaving gaps for an agent selecting or invoking the 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?
The schema covers most parameters with descriptions (75% coverage), so the baseline is 3. The description adds no parameter-specific 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores a non-custodial local wallet session for AI-guided 8DX flows, which identifies the action and resource. It differentiates from sibling tools like eightdx_walletconnect_create_session by specifying 'local' and 'non-custodial', though it doesn't explicitly say 'login'.
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 guidance is provided on when to use this tool versus alternatives such as eightdx_logout_wallet or eightdx_get_wallet_session. The description implies usage for AI-guided 8DX flows but gives no explicit conditions or 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?
With no annotations, the description carries the full burden and does disclose several return behaviors: quote data, a 30-second refresh hint, slippage/deadline metadata, route link metadata, and external signing guidance. It implies non-mutation via 'Previews' but does not explicitly state that no on-chain transaction is sent or mention any side effects or prerequisites.
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 a single well-structured sentence that front-loads the core action and then enumerates the return value categories. Every phrase adds useful information without waste.
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 8 parameters, no annotations, and no output schema, the description lists key return outputs but falls short of explaining critical invocation context, such as optional parameters, required input formats, or whether a wallet connection is needed. It provides a useful outline but not enough to fully guide correct use.
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 description contains no parameter-level information, and schema description coverage is only 63%, leaving parameters like 'slippageBps' without any explanation. It does not compensate for the coverage gap by explaining relationships such as amountIn vs amountInWei or how the API format should be interpreted.
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 uses a specific verb ('Previews') and resource ('market swap'), clearly positioning it as a pre-execution step distinct from 'eightdx_create_swap'. However, it does not explicitly differentiate itself from the sibling 'eightdx_get_quote', relying on the phrase 'AI-guided flow' to imply additional context.
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 'for an AI-guided flow' gives some usage context, implying this tool is meant for a guided preview before a swap, but it does not explicitly state when to use it over alternatives like 'eightdx_get_quote' or when it should be skipped. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool 'gets' an address, implying a read-only operation, but it does not explicitly disclose whether it requires authentication, has side effects, or returns a specific format beyond the name's implication.
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 a single, concise sentence with no unnecessary words. It is front-loaded with the key verb and object.
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?
Despite its brevity, the description is sufficient for the tool's simple interface: one fully-specified parameter and a clear result (the permit contract address). It lacks any mention of related tools or return format, but given the low complexity and rich schema, the context is adequately 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 schema already provides 100% coverage for the single 'blockchain' parameter, including an enum and description. The tool's description adds no additional meaning beyond the schema, so the 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's function: 'Gets the permit contract address for a supported 8DX blockchain.' It uses a specific verb ('gets') and a resource ('permit contract address'), and the scope ('for a supported 8DX blockchain') distinguishes it from other permit-related tools like eightdx_get_permit_data.
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 guidance is provided on when to use this tool versus alternatives (e.g., eightdx_get_permit_data). It does not mention prerequisites, typical use cases, or context in which another tool would be more appropriate.
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?
With no annotations, the description carries the burden of behavioral disclosure. It usefully states the tool is non-custodial, non-signing, and non-sending, which are important safety traits. However, it does not explain whether it performs network calls, what the calldata output looks like, or how permit/slippage/simulation parameters affect 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 two sentences, front-loads the core purpose, and uses the second sentence to state critical exclusions. Every clause earns its place with no wasted words.
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?
For a complex tool with 9 parameters, nested objects, no output schema, and no annotations, two sentences are insufficient. It lacks guidance on how to obtain a 'quoted path,' how the permit flow works, what the calldata is used for next, and any failure/edge-case behavior.
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 only 33%, and the tool description adds no parameter-level meaning beyond referencing 'a quoted path.' It does not explain slippageBps, skipSimulation, usePermit, or fromAddress, leaving the agent to infer their semantics from names alone.
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 and resource: 'Creates swap calldata from a quoted path.' It also clarifies what the tool does not do (sign, send, custody), which distinguishes it from transaction-sending and signing siblings like eightdx_wallet_send_transaction and eightdx_local_sign_and_send_transaction.
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 'from a quoted path' implies usage after eightdx_get_quote, and the explicit negative constraints ('does not sign... does not send... does not custody') provide some when-not guidance. However, it does not explicitly name alternatives or state when to prefer this tool over preview_market_swap or create_limit_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the 'active' scope and read-like behavior ('Gets'), but does not state authentication requirements, return format, pagination, or error behaviors. This is a significant transparency gap.
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 a single sentence that is direct and free of redundant wording. It earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 2-parameter read tool, but it lacks usage context (e.g., when to use vs alternatives) and return value structure, especially since there is no output schema. It also does not mention authentication or side effects.
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 adds no extra parameter meaning beyond what the schema already provides; both maker and blockchain are well-described in the input 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 uses the specific verb 'Gets' with resource 'active 8DX limit orders' and scope 'for a maker address', clearly distinguishing it from sibling tools like get_limit_order_history or get_order_status.
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?
No explicit when-to-use or exclusions are provided. The active-orders-by-maker purpose is implied, but the description does not mention alternatives such as get_limit_order_history for historical orders, nor prerequisites like authentication.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a useful non-obvious behavior: returning block explorer links for filled transaction hashes. However, it does not mention potential outcomes for unfilled orders, error handling, or whether any side effects occur (though 'gets' implies read-only). The description is partially transparent but lacks depth.
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 a single concise sentence that front-loads the core function ('Gets an 8DX limit order by hash') and adds one relevant detail. There is no redundant wording or unnecessary information, making it highly efficient.
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 tool with two parameters and no output schema, the description provides the basic purpose and one return aspect (explorer links). However, it does not clarify the full return structure, such as what status fields are included or what happens when the order is not found. Given the absence of annotations and output schema, more detail would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100% (both parameters are described in the schema), the baseline is 3. The description adds minimal value beyond the schema: it confirms orderHash is used as the lookup key but does not elaborate on blockchain values or add any new semantic insights.
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: 'Gets an 8DX limit order by hash' with a specific verb and resource. It also distinguishes itself from sibling tools like get_limit_orders_by_maker (list by maker) and get_limit_order_history (historical orders) by focusing on single order lookup by hash.
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 'by hash' implies this tool is for querying a specific order when you have its hash, but it does not explicitly mention alternatives or when not to use it. There is no guidance comparing it to get_limit_orders_by_maker or get_limit_order_history, so usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral disclosure. It reveals an important trait (does not create signatures), but omits other relevant details such as whether the cancellation is broadcast, side effects, or success/failure handling. The core mutation is implied but not elaborated.
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 sentences, front-loaded with the action and a key constraint. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, the description is functional but minimal. It explains the prerequisite for the signature but gives no information about return values, errors, or irreversible effects, leaving the agent to infer critical operational 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?
Schema description coverage is 100%, with each parameter already described. The description adds no additional parameter meaning beyond what the schema provides, 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 action ('Cancels an 8DX limit order') and the specific prerequisite ('using an already signed cancel payload'), differentiating it from sibling tools like create_limit_order. The added note that it does not create signatures further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for when a signed cancel payload exists, and explicitly states it does not create signatures, which rules out using it for signing. Although it doesn't name alternative tools, it provides enough context to guide selection.
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?
No annotations are provided, so the description must disclose behavioral traits on its own. It states the mutating action ('signs and broadcasts') and the confirmation requirement, which adds safety context. However, it does not mention the irreversible nature of broadcasting, potential failure modes, or what happens if the signer is not enabled, leaving gaps for a mutation tool.
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, front-loaded with the core action. It includes critical prerequisites without any fluff. Every word earns its place, making it highly efficient.
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?
With no output schema, the description should explain what the tool returns (e.g., transaction hash) but does not. It also omits details like network-specific behavior or gas handling. However, it does cover the essential action and prerequisites, making it minimally sufficient but not fully 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 schema already documents all parameters with descriptions. The tool description adds no extra parameter-level detail beyond the schema's existing coverage, which aligns with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Signs and broadcasts') and the specific resource ('a prepared transaction with the opt-in local signer'). It distinguishes itself from the sibling tool 'eightdx_wallet_send_transaction' by explicitly mentioning the local signer, making the tool's role 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?
Provides clear prerequisites: EIGHTDX_ENABLE_LOCAL_SIGNER=true and explicit user confirmation. This defines when the tool is applicable, though it does not explicitly name the alternative (wallet-based sending) or state when not to use it. The context is strong enough for an agent to infer appropriate use.
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?
With no annotations, the description carries the burden of behavioral disclosure. It highlights the critical requirement of explicit user confirmation and the WalletConnect signing path. However, it omits other behavioral details such as irreversibility, error handling, or prerequisites like an active WalletConnect session.
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?
A single, focused sentence that states the core action and key requirement. No redundant words, and the important constraint (user confirmation) is included concisely.
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 7 parameters, no output schema, and no annotations, so the description needs to provide enough context. It explains the core flow but lacks guidance on how the transaction is prepared, dependencies on WalletConnect sessions, or what the response indicates on success/failure. This leaves some gaps for an agent to misuse the 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?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds little beyond the schema, only reinforcing that the transaction is 'prepared' and that user confirmation is needed, which is already in the confirmedByUser parameter 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: requesting the connected wallet to sign and broadcast a prepared transaction via WalletConnect eth_sendTransaction. It is distinct from siblings like eightdx_local_sign_and_send_transaction by explicitly specifying the WalletConnect mechanism.
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 when to use the tool (for a prepared transaction that needs wallet confirmation and broadcast) but does not explicitly contrast it with alternatives like local signing or other send methods. It provides clear context but no exclusions or alternative names.
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?
With no annotations provided, the description carries the full burden. It discloses that order hashes are not chain transactions and will be explained rather than linked, which is a meaningful behavioral trait. However, it does not mention return format (e.g., URL or message), error handling, or any required permissions, leaving some gaps.
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 a single sentence that starts with the action verb and resource, then lists the accepted value types and the special order-hash behavior. No unnecessary words or 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 tool with no output schema, the description adequately covers the main purpose and the special case. It could explicitly state the return format (e.g., a URL string), but the agent can infer it from 'builds a link'. Overall, it is complete enough for correct invocation.
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 each parameter having a description and two parameters having enums. The description adds no additional parameter-level meaning beyond what the schema already provides, so the 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 a specific verb 'Builds' and a distinct resource: 'chain-specific block explorer link'. It enumerates the value types (transaction, address, token, order) and clearly differentiates from sibling tools that handle swaps, orders, or wallet sessions. The special case for order hashes further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a block explorer link is needed for a transaction, address, token, or order hash. It does not explicitly name alternatives, but no sibling tool serves this purpose, so the context is clear. The note about order hashes being explained rather than linked gives a useful exclusion.
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?
With no annotations provided, the description carries the full burden. It discloses the conditional behavior ('if one is set') and the session type (non-custodial), but does not specify the return format or error behavior when no session exists. This is acceptable for a simple getter but lacks richer detail.
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 a single, front-loaded sentence with no redundant words. Every word adds value, making it highly concise and well-structured.
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, no annotations), the description adequately covers its purpose and conditional nature. It could optionally mention what is returned when no session is set, but overall it is complete enough for a trivial 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?
The tool has zero parameters, and the schema is empty. The baseline score for 0-parameter tools is 4, and the description correctly implies no inputs are required, so it adds appropriate meaning without needing further parameter explanation.
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 returns the current local non-custodial wallet session, using the specific verb 'Returns' and a well-defined resource. The qualifiers 'local' and 'non-custodial' help distinguish it from sibling tools like eightdx_walletconnect_get_session, making 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to get the local wallet session) but provides no explicit guidance on when not to use it or how it compares to alternatives such as eightdx_walletconnect_get_session. The 'local non-custodial' wording offers context, but no direct exclusions or alternative references are given.
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?
No annotations are provided, so the description carries the full burden. It discloses the core behavior (reachability check) but does not clarify what constitutes a successful check (e.g., HTTP status), the response format, or any side effects. For a health check, this is minimal but viable.
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 a single, front-loaded sentence that directly states the tool's purpose without any unnecessary words. Every word 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?
This is a simple health-check tool with no parameters and no output schema. The description sufficiently conveys the core purpose for a tool of this complexity, though it could be more specific about what 'reachable' means or what the response indicates.
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 the schema is empty. The description need not add parameter details; the baseline of 4 applies as no parameter information is missing.
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 the specific verb 'checks' and clearly identifies the resource as the 'configured 8DX REST API' reachability. This distinguishes it from sibling tools that perform transactions, searches, or wallet operations.
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?
Usage context is implied rather than explicit. The description states the tool checks API reachability, which suggests using it to verify connectivity, but it does not provide explicit guidance on when to use it versus alternatives or how it fits into a workflow.
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?
With no annotations, the description carries the full burden. It discloses that the wallet, not MCP, signs transactions and lists the output types. However, it does not mention side effects, prerequisites, or session persistence, leaving some behavioral ambiguity.
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, two sentences, with the main purpose and outputs front-loaded. It does not waste words and is easy to parse.
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 simple one-parameter schema and no output schema, the description adequately covers the return values (QR/raw URI, copied URI, deeplink) and the signing behavior. It could mention the required blockchain parameter, but the schema already covers that.
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 parameter 'blockchain' has a clear enum and description. The tool description adds no additional parameter context, so a baseline 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's action: 'Creates a WalletConnect session' and specifies the exact outputs (QR/raw URI, copied URI, mobile deeplink). It distinguishes from siblings like walletconnect_get_session by emphasizing creation rather than retrieval.
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: this tool creates a session and returns connection options, implying it is for initiating a new session. It also clarifies the wallet's signing role, but it does not explicitly name alternatives or provide exclusion conditions.
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?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool is idempotent when no session exists ('if one exists'), which is useful, but it does not describe side effects (e.g., whether local state is cleared, if it's reversible, or whether authentication is required). For a disconnect action, this is minimal.
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 a single, concise sentence that immediately communicates the action and the key condition. Every word earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description sufficiently covers the essential action and the conditional behavior. It lacks explicit return-value information, but given the simplicity of the tool, this is not a critical omission.
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 there is nothing for the description to explain. The baseline for 0 parameters is 4, and the description is unaffected by parameter-related gaps.
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?
Clearly states the specific action: disconnecting the current WalletConnect session. The verb 'Disconnects' and resource 'current WalletConnect session' precisely identify the tool's function, distinguishing it from siblings like create_session, get_session, and logout_wallet.
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 a WalletConnect session exists and needs to be disconnected, but does not explicitly mention alternatives or when not to use it. The conditional phrase 'if one exists' provides some context, but there is no explicit guidance relative to sibling session management 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a critical behavioral trait: the tool expects an already signed payload and does not perform signing. This is valuable and not obvious from the tool name. However, it does not disclose other potential behaviors such as return format, transaction costs, or wallet connection requirements, so it is not fully transparent.
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 consists of two concise sentences that front-load the primary action and immediately clarify the key prerequisite. Every word contributes meaningful information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema, no annotations), the description is relatively minimal. It covers the essential prerequisite (signed payload) but does not explain what happens after submission, expected return values, or how to obtain the required signature. The schema fills in many parameter details, so it is not completely inadequate, but there are clear gaps 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?
The description itself provides no parameter-level guidance. The input schema has a moderate 71% description coverage, with many fields documented, but some nested objects like 'makerTraits' are only vaguely described as 'produced by the 8DX limit-order signing flow.' The tool description does not compensate for these gaps, so the parameter semantics are adequate but not enhanced.
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 action ('submits an already signed 8DX limit order payload') and clearly identifies the resource. It explicitly distinguishes itself from signature-creating tools by saying 'This tool does not create signatures,' making the purpose unambiguous and differentiated from siblings like eightdx_create_swap or signing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you have an already signed order. It also provides a when-not-to-use by stating it does not create signatures, which implicitly excludes this tool for signing tasks. However, it does not explicitly name alternatives or describe the full workflow (e.g., signing tools to use first), so it falls slightly 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It accurately indicates this is a search (and therefore likely read-only), but it does not explicitly state safety/auth implications, return value details, or any rate limits. It adds some context but leaves the agent without full transparency beyond the basic operation.
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 a single sentence that is front-loaded with the core action ('Searches 8DX token metadata') and immediately clarifies the use case. Every word earns its place, with no redundant or vague phrasing.
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?
While the description clearly conveys the tool's purpose and when to use it, it does not explain what the search returns (e.g., the structure of token metadata) or provide details about pagination/ordering beyond what the schema already includes. With no output schema, the description should say more about the response format to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, but the description adds meaningful context for the 'q' parameter by explaining it resolves user phrases like 'BTC, bitcoin, USDC, or a token name.' This goes beyond the schema's 'Token symbol, name, or address search query' and helps the agent know how to construct queries.
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 and resource: 'Searches 8DX token metadata.' It clearly distinguishes this tool from sibling tools by focusing on token resolution/search rather than quoting or swapping, and provides concrete examples (BTC, bitcoin, USDC) that illustrate 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 explicitly states the intended usage context: 'so an AI agent can resolve user phrases ... before quoting.' This gives clear guidance on when to use the tool, though it does not explicitly mention when not to use it or name alternatives, stopping 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?
With no annotations provided, the description carries the full behavioral disclosure burden. It transparently states that the tool 'only returns data to sign' and 'does not sign anything', which is a key behavioral trait and clarifies the tool is non-mutating in terms of on-chain actions. While it doesn't detail side effects, rate limits, or authentication, the core safety-relevant behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and resource. The second sentence adds a critical clarification without redundancy. Every word earns its place, and the structure is optimally 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?
Given there is no output schema and no annotations, the description provides a clear purpose and a key behavioral constraint. It explains that the tool returns data for signing, which is sufficient for an agent to know what to expect and how to use the result in a broader flow. However, it does not describe the output structure or indicate any errors/pagination, which would be useful in the absence of an output schema. Still, it is adequately complete for this tool's 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?
The input schema has 100% description coverage for all four parameters, so the schema already provides detailed meaning. The tool description itself adds no additional parameter-level information. Its reference to 'token approval flow' provides general context but does not clarify any specific parameter semantics beyond what the schema states. 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's function: 'Gets permit typed data for a token approval flow.' It uses a specific verb ('gets'), a distinct resource ('permit typed data'), and provides context (token approval flow). It also clarifies it 'does not sign anything', distinguishing it from signing tools. The purpose is unambiguous and not a tautology.
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 by tying the tool to a 'token approval flow' and explicitly stating it 'only returns data to sign; it does not sign anything.' This tells the agent this is a pre-signing step and implies that signing tools should be used if actual signing is needed. However, it does not explicitly name alternative tools or state when not to use it beyond the non-signing exclusion.
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 no annotations provided, the description carries the burden of behavioral disclosure. It transparently states the tool does not connect or sign, which is a key behavioral trait, and specifies the output format (deeplink and web fallback). While it doesn't mention prerequisites like authentication, the disclosure is sufficient for a simple link-building utility.
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 sentences, front-loaded with the core purpose and followed by a clarifying limitation. Every word earns its place with no 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 link builder, the description covers the outputs and explicitly states the non-connection behavior, which is important context relative to sibling tools. It could mention the return format, but with no output schema and low complexity, the description is reasonably 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%; both parameters have descriptive schema text (routeUrl as the URL to open, walletApp as optional preferred wallet). The tool description adds no additional parameter meaning beyond the schema, so 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 builds wallet handoff links for an 8DX route, specifying output types (MetaMask Mobile dapp deeplink and web fallback). It also distinguishes from siblings by explicitly noting it does not connect or sign, making the purpose unmistakable.
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 tool only builds links and does not perform connection or signing, implying it should be used when links are needed rather than actual wallet actions. However, it does not explicitly name alternative tools or state 'use X instead', so it lacks full exclusion 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?
With no annotations provided, the description fully carries the transparency burden. It discloses the immediate effect (clearing the local session) and explicitly states what it does NOT do (revoke approvals or cancel on-chain permissions), which prevents the agent from assuming broader side effects. It does not mention prerequisites like authentication, but for a simple logout action this is sufficient.
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, with the primary action front-loaded in the first sentence and the key non-effect in the second. Every word contributes meaning, with no filler or repetition of the name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete. It explains the action and its boundaries, which is enough for an agent to invoke it correctly. The negative statement adds important context about scope, making the tool's intent fully understood.
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 the schema is empty. By rule, baseline for 0-parameter tools is 4. The description correctly focuses on behavior rather than parameters, so it adds no conflicting or redundant information.
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 ('Clears') and resource ('current local wallet session'), making the tool's function unambiguous. It also distinguishes itself from related wallet operations by stating it does not revoke approvals or cancel on-chain permissions, which differentiates it from siblings like walletconnect_disconnect or approval-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?
The description clearly states what the tool does and explicitly excludes a common use case ('does not revoke wallet approvals or cancel on-chain permissions'). This gives the agent a clear sense of when to use it (to clear a local session) and when not to (for revocations), though it does not name a specific alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the read-only nature via 'Shows' and provides valuable context about the default state and configuration requirement. No contradictions or hidden behaviors.
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, front-loaded with the core purpose. Every sentence adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-param status endpoint, the description is complete. It states exactly what is shown and the key behavioral context (default disabled, env config required). The return format is inferable from the 'Shows whether' phrasing, so no further detail is necessary.
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 is fully covered. Per guidelines, a 0-param tool gets a baseline of 4; the description doesn't need to add parameter details and doesn't omit any relevant info.
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 'Shows whether the opt-in local signer is enabled', using a specific verb and resource. This distinguishes it from sibling signing tools like 'eightdx_local_sign_and_send_transaction' by focusing on a read-only status check.
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 by explaining that local signing is opt-in, disabled by default, and requires explicit environment configuration. This implies when the tool is useful (to verify if local signer is available), though it doesn't explicitly name alternatives.
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:

[![8dx-mcp-server MCP server](https://glama.ai/mcp/servers/8DX-io/8dx-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/8DX-io/8dx-mcp-server)

Score Badge

Copy to your README.md:

[![8dx-mcp-server MCP server](https://glama.ai/mcp/servers/8DX-io/8dx-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/8DX-io/8dx-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/8DX-io/8dx-mcp-server'

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