Strata MCP

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation5/5
Each tool targets a distinct stage or resource: discovery, market data, quoting, and the challenge/prepare/submit flows for both execution and order workflows. The parallel execution/order tools are clearly differentiated by quote-bound vs. order-bound descriptions.
Naming Consistency5/5
All tools share the strata_ prefix and use snake_case with a clear noun or verb_noun structure. The challenge/prepare/submit parallel is consistent, and status/capabilities/markets/quote are predictable.
Tool Count5/5
Eleven tools is well within the ideal scope and the count is justified by the domain's need for discovery, market data, quoting, and signed execution/order lifecycles. No tool feels redundant.
Completeness4/5
The set covers the full external-signing lifecycle: capabilities, action graph, markets, quotes, challenge, prepare, submit, and order status. The main minor gap is no dedicated execution-status recovery tool analogous to order_status, though idempotency keys mitigate this.
Average 3.6/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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?
Annotations declare readOnlyHint=false and destructiveHint=true, but the description says 'bind to canonical bytes for the external signer', which suggests a transformation rather than an execution—potentially contradicting the destructiveHint. It doesn't disclose that it handles mutable operations (place/cancel/replace) or that it might submit transactions. The ambiguity about whether this tool actually executes trades or just prepares bytes is a transparency gap, especially given the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it's dense and uses domain-specific terminology without clarification. It could be considered appropriately short for a title that matches, but the lack of structure (no paragraphs, no examples) reduces clarity. It doesn't front-load the most critical info about what it does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—12 parameters, nested batch operations, and a destructive hint—the description is drastically incomplete. It lacks usage context, return behavior (though no output schema), and clarification of the challenge/prepare/submit workflow. An agent would struggle to use this tool correctly based solely on the description.
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?
With only 8% schema description coverage and 12 parameters, the description offers zero guidance on parameter semantics beyond the jargon. It doesn't explain key parameters like marketId, ownerWallet, sessionPublicKey, or the structure of operations. The schema has some descriptions (accountSequence) but the tool description fails to compensate for the widespread lack of context, making it hard for an agent to construct valid requests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specialized jargon ('bind an atomic place, cancel, cancel-all, replace, or bounded batch request to canonical bytes') that obscures the actual purpose. It doesn't clearly state that this is an order challenge tool for the Strata protocol, and the verb 'bind' is vague. While it lists the actions, it fails to distinguish from siblings like strata_order_submit or strata_order_prepare.
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 doesn't explain the tool's role in the signing flow, nor does it mention prerequisites like the need for a session key or when to use batch operations. The sibling names suggest a prepare/submit workflow, but this description doesn't clarify its place in that flow.
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?
While the annotations indicate destructive behavior (destructiveHint: true), the description itself does not elaborate on side effects, permissions required, or consequences of the operation. The term 'prepare' is ambiguous—it could mean a transaction preparation or an actual execution—which reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and free of fluff, but it is overly brief, omitting essential details that would make it informative. It is appropriately sized in length but not in content richness, balancing brevity against clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is far from complete. It does not cover important aspects such as return values, error scenarios, prerequisites, or the expected behavior when allowedWalletAddresses is empty. Given the complexity of a policy operation, this level of incompleteness is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the parameters. It mentions 'blocked' and 'restricted' but does not clarify how 'allowedWalletAddresses' is used or what each mode entails. The schema provides the structure but lacks semantic meaning, and the description adds no value to parameter understanding.
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 ('prepare a policy') and specifies the two modes ('blocked' or 'restricted'), which distinguishes it from other vault-related tools. However, it could be more explicit about the exact outcome of the policy preparation.
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 does not provide guidance on when to use this tool versus others, nor does it explain the difference between 'blocked' and 'restricted' modes. It only mentions 'owner-authorized', which implies the intended user but lacks contextual usage instructions.
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 annotations mark the tool as destructive (destructiveHint: true) and non-idempotent, but the description does not warn about these properties. Instead, it only mentions that upsert 'fails closed', which is insufficient behavioral disclosure for a destructive operation. This is a significant gap given the annotations are not explained.
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 brief and gets to the core purpose in two sentences. The first sentence front-loads the main action and the second adds a critical constraint. It is concise, though it packs several concepts into the second sentence, which slightly reduces readability.
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 tool is complex with 15 parameters, no output schema, and no documentation of return values or errors. The description only hints at one condition (verified reference) and omits prerequisites like maker wallet funding, permissions, or how the unsigned transaction will be returned. The absence of any parameter explanation or usage flow makes it incomplete for a non-trivial operation.
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?
With 0% schema description coverage and 15 parameters, the description does not explain any parameter semantics beyond the action and the market reference requirement. The schema itself provides types and constraints, but the description fails to clarify how the many BPS and depth parameters interrelate or which are required for upsert vs cancel.
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 it builds 'one exact unsigned maker-owned Current transaction' and distinguishes between upsert and cancel behavior with the 'fails closed' clause. It differentiates from siblings by using 'Current' in the name and description, but doesn't explicitly name a sibling to contrast against.
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 mentions that upsert requires a verified on-chain reference while cancel does not, which provides some context for when each action is appropriate. However, it lacks guidance on when to use this tool versus the sibling 'strata_market_making_strand_prepare' or when to prefer the submit tool, leaving the agent to infer selection criteria.
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 readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds the notion of 'externally authorized' and 'for a new wallet,' which is useful context, but it doesn't disclose what happens during submit or what authorization is needed. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. However, it's under-specified, so it's concise at the expense of clarity.
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 tool with three parameters and no output schema, the description is too sparse. It doesn't explain the prepare vs submit distinction, the need for authorizationSignature, or the expected outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not mention walletAddress, referralCode, or authorizationSignature, nor map them to roles. The title and text give only a weak hint about a new wallet and external authorization.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Prepare or submit' which offers two possible actions rather than a single clear verb, and it doesn't distinguish this tool from sibling tools like strata_referral_claim or strata_referrals. It does identify the resource (referral link) and target (new wallet), so it's 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool vs alternatives. The phrase 'externally authorized' implies a prerequisite but no explicit when-to-use or exclusion criteria.
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?
The annotations indicate destructive, non-idempotent, and open-world behavior, but the description adds no additional details about side effects, irreversibility, or required permissions. It does not disclose potential consequences or state changes beyond the generic 'revocation' context. For a destructive operation, more transparency about the nature and impact is expected.
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 single, concise sentence with no redundancy or fluff. It is well-structured and easy to read. However, it is perhaps too brief given the complexity of the operation, but conciseness itself is not penalized; the sentence is efficient and clear in its wording.
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 lacks essential context about the purpose and usage. It does not explain what 'owner-authorized' means in practice, what 'externally held' refers to, or what 'prepare' implies (e.g., does it create a transaction that needs confirmation?). There is no output schema, so no information about return values. The description is too sparse to fully inform an agent about when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines three parameters (action, walletAddress, sessionPublicKey) with no descriptions, and the tool description does not explain any of them. The description mentions 'owner-authorized' and 'session key' but does not map these to the parameters. With zero schema coverage, the description entirely fails to clarify parameter meanings, leaving the agent to guess the role of each field.
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 prepares an owner-authorized revocation of a Vault session key, which is a specific and distinct action among the sibling tools. The mention of 'owner-authorized' and 'externally held' adds useful context. However, 'prepare' is slightly ambiguous—it could imply a preliminary step rather than the actual revocation, but the intent is still clear.
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, nor any preconditions or scenarios. It lacks explicit instructions on when this tool should be invoked, leaving the agent to infer from the tool name and brief description. There is no comparison to sibling tools like strata_vault_revoke or strata_vault_submit.
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 indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description does not contradict these, but it adds limited transparency by noting that the request requires external authorization, which is a key constraint. However, it does not disclose what happens upon submission, whether it is a state-changing action (consistent with readOnlyHint=false), or what 'prepare' entails. With annotations present, the description covers some but not all context.
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?
One sentence, no fluff, and front-loaded with the action. However, the phrasing is a bit verbose with 'externally authorized request' and 'currently claimable' but still concise. It could be improved by adding more specifics, but it is not bloated.
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 presence of an authorizationSignature and the prepare/submit pattern, the tool is likely part of a multi-step flow, but the description does not explain the workflow, prerequisites, or what happens next. There is no output schema, and schema coverage is 0%, so more detail is needed to make the tool usable. The complexity is medium (3 params, mutation), but the description falls short.
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 0%, so the description must explain parameters, but it does not. The description mentions 'externally authorized request' implying that authorizationSignature is needed, but it does not clarify the exact role of each parameter: walletAddress, payoutWalletAddress, and authorizationSignature. The schema has regex patterns but no descriptions, so the agent must infer meaning from the name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'prepare or submit' and identifies the resource as 'an externally authorized request for currently claimable referral rewards.' This includes the scope ('currently claimable') and hints at the external authorization requirement. However, it does not clearly distinguish this from sibling tools like strata_referrals or strata_rewards, nor does it specify what 'prepare' means vs 'submit.'
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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions 'externally authorized request' but does not explain what steps precede this or when submit vs prepare is appropriate. No alternative tools are named, and the context of use is only implied by the words 'prepare or submit'.
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?
The annotation readOnlyHint=true already covers the read-only safety profile. The description adds the 'short-lived' nature, implying the quote expires quickly, which is behavioral context beyond annotations. However, it does not elaborate on expiration behavior or other operational details like rate limits or authorization.
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 single, concise sentence that front-loads the primary purpose. It has no fluff, though it could be slightly clearer with less jargon, but efficiency is good.
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?
With no output schema and no schema descriptions, the description should cover what the tool returns, parameter constraints, and behaviors. It does not explain the return value format (e.g., price, output amount, fees) or mention the optional maximumToleranceBps parameter. The description leaves too many gaps for a quote tool.
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 0%, so the description must explain parameters. It only hints at asset IDs and an input amount ('exact-input') but does not explain amountInAtoms, maximumToleranceBps, or the meaning of the response. This is insufficient for 4 parameters with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it requests a 'short-lived exact-input customer economics' between two asset IDs, which conveys the core function of obtaining a quote for swapping a specified input amount. It also distinguishes to some degree from sibling tools like strata_exact_output_quote by explicitly noting 'exact-input'.
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 strata_quote or strata_exact_output_quote. It does not mention use cases, prerequisites, or conditions under which this should be preferred.
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 communicate that the operation is not read-only, not idempotent, and not destructive. The description adds useful context that the tool returns exact bytes for an external signing step and that the schedule is bounded. Still, it does not disclose side effects, whether on-chain state changes, or how the returned bytes are meant to be used.
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 single, front-loaded sentence with no filler. It is concise and places the verb and object early, but the brevity borders on under-specification given the tool's complexity.
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 complex tool with 9 required parameters, no output schema, and no usage context. The description only identifies the output kind and bounded schedule, omitting prerequisites, return format, relationship to submit/cancel tools, and behavioral expectations, so it is not complete enough for reliable agent 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?
Schema description coverage is 0% across 9 required parameters. The phrase 'bounded TWAP schedule' gives only a high-level hint and does not explain the meaning or grouping of parameters like marketId, sessionPublicKey, slicesTotal, maximumToleranceBps, intervalSlots, or limitPriceAtoms. The description adds minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Request exact external-signing bytes' for 'a bounded TWAP schedule.' This avoids tautology and clearly conveys the tool's core action. However, it does not explicitly differentiate itself from closely related siblings such as strata_twap_prepare or strata_twap_submit.
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 usage guidance is provided. The description does not say when to call this tool, whether it should precede strata_twap_submit, how it differs from strata_twap_prepare, or what prerequisites must hold before requesting signing bytes.
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?
The description focuses on preparation and signing but does not mention any side effects or state changes. Given the annotations indicate destructiveHint=true and readOnly=false, the description should disclose potential impacts (e.g., cancelling orders) but remains silent on this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (two sentences) but includes parenthetical asides that make it slightly convoluted. It could be more direct and structured for clarity.
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 tool with 14 parameters and no output schema, the description is insufficient. It does not explain the returned transaction, how to use it afterwards, or what the output format might be. The description lacks essential context for a developer to use the tool effectively.
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 has many parameters with zero coverage, and the description only hints that some fields are part of the 'operation itself' and that challengeId+authorizationSignature is an alternative. It does not explain the meaning or role of most parameters like ownerWallet, sessionPublicKey, or limitPriceAtoms.
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 prepare an immutable partially signed order-control transaction. It specifies the verb 'Prepare' and the object 'order-control transaction', which is specific and distinct from other tools.
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 mentions two ways to use the tool: passing the operation itself or using a challengeId+authorizationSignature from strata_order_challenge. It implies a relationship with sibling tools but does not explicitly state when to use this versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate that. It adds 'owner-authorized' and 'exact' which are useful context, but does not disclose what happens after preparation (e.g., does it create a transaction? Does it require a subsequent submit step?). 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?
The description is a single, concise sentence that is front-loaded with the key action. It is efficient, though it could add a bit more detail without becoming verbose.
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 5 required parameters, no output schema, and no parameter descriptions, the description is too sparse. It does not explain the workflow (prepare vs submit), what the output is, or any side effects. Sibling tools like strata_vault_submit suggest a multi-step process, but this description doesn't clarify the tool's role in that process.
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 0%, so the description must compensate. It mentions 'destination wallet' and 'amount' implicitly, but does not explain the meaning of walletAddress, marketId, assetId, or amountAtoms beyond what the schema patterns show. The description adds minimal value for parameter understanding.
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 ('Prepare an exact owner-authorized withdrawal') and the resource ('Strata Vault') with a destination wallet. It distinguishes from sibling tools like strata_vault_deposit and strata_vault_submit by specifying 'withdrawal' and 'owner-authorized', though it doesn't explicitly contrast with those siblings.
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 preparing a withdrawal, but does not explicitly state when to use this tool versus alternatives like strata_vault_submit or strata_vault_pause. It lacks guidance on prerequisites (e.g., vault setup, authorization) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, implying side effects or external interactions. The description adds minimal behavioral context—it does not disclose what happens when called, what the authorization bytes are for, or conditions like quote expiration. It relies on the schema for quoteId validation but omits the purpose of the bytes.
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 unnecessary words, efficiently conveying the core action.
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 tool has no output schema, yet the description does not explain the return format or usage of the authorization bytes. It also fails to place itself in the execution flow with sibling tools like prepare/submit, making it incomplete for a multi-step process.
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 all parameters have clear descriptions (e.g., quoteId pattern, ownerWallet length). The tool description adds no additional parameter semantics, but the baseline of 3 is appropriate since the schema already carries the burden.
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 requests canonical quote-bound authorization bytes for an external signer, which is a specific verb and resource. 'Quote-bound' distinguishes it from other challenge tools like strata_order_challenge or strata_twap_challenge.
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 the other execution/order tools, nor does it mention prerequisites or the intended flow. It simply states the function without contextual placement among siblings.
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, destructiveHint=true, and idempotentHint=true, and the description does not contradict them. It adds useful context by emphasizing the transaction is 'exact' and 'externally maker-signed' and that a 'stable retry key' supports safe retries, but it does not describe the irreversible on-chain effects beyond what destructiveHint already 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-formed sentence with no filler. Key qualifiers ('exact', 'externally maker-signed', 'stable retry key') are front-loaded and each 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?
Given that this is a destructive, on-chain submission tool with four required parameters, no output schema, and no relationship to prepare/current siblings described, the description is too sparse. An agent would need to inspect sibling tools or external docs to know the full submission flow, retry behavior, and expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries most of the parameter-meaning burden. It gives real semantics for signedTransactionBase64 ('exact externally maker-signed Strand transaction') and idempotencyKey ('stable retry key'), but marketId and makerControlId are left implicit despite being required. This is partial compensation for low 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 a specific verb ('Submit') and a concrete resource ('externally maker-signed Strand transaction'), plus a useful qualifier ('stable retry key'). It clearly states what the tool does, but does not explicitly distinguish it from sibling tools such as strata_market_making_strand_prepare or strata_market_making_current_submit.
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 given about when to call this tool versus the prepare or current_submit siblings, and there is no mention of prerequisites or flow placement. The only implicit cue is the word 'Strand' in the name and description, which is insufficient for confident routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description doesn't need to repeat those. The description adds the 'stable retry key' concept, which implies idempotent retry behavior, but doesn't disclose what happens on failure (e.g., whether the order is partially executed, whether it can be retried safely). With annotations covering the safety profile, the description adds some value but not rich behavioral context.
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 single, concise sentence that front-loads the core action. It's efficient with no wasted words, though it could benefit from a brief note on prerequisites or retry behavior without becoming 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?
Given the tool's complexity (4 required params, no output schema, no annotations beyond hints), the description is adequate but not complete. It doesn't explain the relationship between orderControlId and the signed transaction, nor what the response contains. The sibling tools suggest a multi-step flow (challenge -> prepare -> submit), but the description doesn't clarify where this fits in that flow.
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 0%, so the description must compensate for parameter meaning. The description mentions 'externally signed order transaction' and 'stable retry key', which maps to signedTransactionBase64 and idempotencyKey, but it doesn't explain marketId or orderControlId. The description adds minimal value beyond the schema's patterns, leaving the agent to infer the purpose of each parameter from names alone.
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 ('Submit an externally signed order transaction') and the key resource ('order transaction'), with a specific qualifier ('with a stable retry key'). It distinguishes from siblings like strata_order_prepare and strata_order_status by focusing on submission of a signed transaction, though it doesn't explicitly name alternatives.
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: it's for submitting an already-signed order transaction, which suggests it should be used after preparation steps. However, it doesn't explicitly state when not to use it or mention alternatives like strata_order_prepare or strata_execution_submit. The 'stable retry key' hints at idempotent retry usage but doesn't elaborate.
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?
The annotations already communicate the safety profile (readOnly=false, destructive=true, idempotent=true). The description adds value with the 'exact' trait, confirming the tool relays the exact transaction without modification. However, given destructiveHint=true, one would hope for some behavioral disclosure about what happens upon submission (e.g., replaces prior control), which is absent.
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?
A single 13-word sentence that leads with the verb and subject and packs meaningful qualifiers ('exact', 'externally maker-signed', 'stable retry key') into dense, valuable space. If anything, it's almost too terse given the complexity of what's being submitted.
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?
There are 75+ siblings with confusion pairs like strand_submit vs. current_submit, and no output schema to convey the response contract. For a destructive mutation, the description doesn't explain what 'Current' control means versus 'Strand,' whether submitting replaces something, or how one obtains a makerControlId — leaving an agent significantly under-equipped.
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?
With 0% schema description coverage, the description carries the full burden, and it does shed some light: 'exact externally maker-signed' clarifies signedTransactionBase64 semantics, and 'stable retry key' usefully frames idempotencyKey as a value that must be fixed across retries. However, the description offers no added meaning for marketId or makerControlId — an agent still wouldn't know what a makerControlId is or where to get one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (submit) and resource (externally maker-signed Current transaction), with the qualifier 'exact' adding meaningful distinctiveness — this tool does not re-sign or construct anything, it relays bytes. The phrase 'externally maker-signed' also differentiates this from prepare-style siblings, though it doesn't name them explicitly.
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 precondition for use — that an external maker has already produced a signed transaction — is clearly implied by 'externally maker-signed'. However, the description never states when NOT to use this (e.g., 'if you don't have a signed transaction, call current_prepare'), nor does it proactively name between strand_submit and current_submit.
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 readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=true. The description restates idempotency and adds the 'exactly externally signed' constraint, but it does not explain what the destructive behavior entails, what side effects occur, or any auth/rate-limit considerations.
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, focused sentence with no filler. Key qualifiers are front-loaded and every word adds meaning relative to the tool name.
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?
With 4 required parameters, no output schema, and no reference to the surrounding prepare/challenge/submit flow, the description is not sufficient for an agent to confidently invoke the tool or interpret the result. It lacks prerequisites, expected side effects, and relationship to sibling tools.
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 has 0% description coverage and 4 required parameters. The description only weakly maps to signedTransactionBase64 via 'externally signed' and to idempotencyKey via 'idempotently'; it does not explain marketId, twapControlId, or how the parameters relate to the TWAP flow.
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 identifies the action ('Submit') and the resource ('exact externally signed TWAP transaction'), distinguishing it from related tools like strata_twap_prepare and strata_twap_cancel. It adds qualifiers about the transaction being externally signed and idempotent, making the scope specific.
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 about when to use this tool versus alternatives such as strata_execution_submit, strata_order_submit, or other TWAP flow steps. The phrase 'exactly externally signed' implies a prior signing step, but prerequisites and retry conditions are never explicitly described.
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 establish that this is read-only, idempotent, and non-destructive. The description adds the 'public' scope and the categories returned, but it does not clarify response size, pagination, or what 'live availability gate' means. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition. It is concise, though the list of returned categories is dense and somewhat jargon-heavy.
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 parameterless read-only discovery tool with strong annotations, the description covers the high-level contents of the graph and is enough to understand the tool's purpose. However, without an output schema, it leaves the exact return format and the meaning of 'live availability gate' implicit.
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 by default. The description correctly implies a parameterless, whole-graph discovery operation, and no parameter-level explanation is needed.
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 names the resource ('platform graph') and identifies the categories exposed: modules, entity relationships, operation bindings, workflows, and availability gates. It is specific enough to convey what the tool does, though it does not explicitly differentiate it from sibling tools such as strata_action_graph.
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?
There is no guidance about when to use this tool versus the many sibling tools, no exclusions, and no mention of alternatives. The broad 'Discover every...' phrasing implies a general discovery role, but the description does not state usage 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 readOnlyHint=true and destructiveHint=false, so the description adds value by noting the data is 'sanitized' and specifically returns progress and terminal receipts. This gives behavioral context beyond the safety annotations, though it doesn't mention authentication or rate limits.
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 fluff. It conveys the core operation immediately without any unnecessary 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?
With no output schema and no parameter explanations, the description is inadequate for a tool with two required parameters. It fails to explain the return format (beyond 'progress and terminal receipts'), the role of marketId, or any usage prerequisites, making it incomplete 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain the parameters. marketId and walletAddress are only defined by their regex patterns, and the description's mention of 'wallet-owned' hints at walletAddress but provides no detail on format or semantics.
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 it reads TWAP progress and terminal receipts for wallet-owned schedules, using a specific verb and resource. It distinguishes from write tools like strata_twap_submit, but omits the marketId parameter from the purpose, so it's not fully complete.
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 TWAP progress, but provides no explicit guidance on when to use this tool versus alternatives like strata_twap_challenge or strata_order_status. No exclusions or alternative tool recommendations are given.
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?
Annotation indicates destructiveHint=true, but description says the tool builds an unsigned transaction, which is not destructive itself. This contradiction makes the description misleading about the tool's actual 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 concise and well-structured: it states the purpose, unit conventions, and workflow in three short sentences without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it provides sufficient context about the tool's role in the overall market-making workflow, including the need for external signing and subsequent submission. Lacks details on return values, but that is not critical here.
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?
Description mentions all exposures and level sizes are in base-atoms, providing some meaning for size-related parameters, but fails to explain most parameters (action, offsets, syncSpreadTicks, etc.). With 14 parameters and 0% schema description, semantics are largely 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?
States it builds an unsigned maker-owned Strand transaction, which is specific and distinct from the submit step. The purpose is clear and 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 a workflow: build externally, sign, then submit with the Strand submit tool. Implicitly differentiates from other tools but does not explicitly state when to use this over other prepare 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, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the context that availability is 'current', implying live data, but does not disclose response format or any edge cases.
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, clear sentence with no wasted words. It is front-loaded and easy to parse.
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 is simple with one optional parameter and no output schema, but the description does not clarify the return structure or what 'Sonar quote availability' entails. Given the lack of an output schema, a bit more detail about response data would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (includePaused) is fully documented in the schema with a clear description, and schema coverage is 100%. The tool description does not add any additional meaning beyond what the schema already 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 uses a specific verb ('List') and identifies the resource ('Strata markets') plus a distinguishing aspect ('current Sonar quote availability'). It clearly differentiates from sibling tools like strata_quote and strata_capabilities.
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 sibling tools (strata_capabilities, strata_quote). It does not mention use cases, prerequisites, or alternatives, leaving the agent to infer context.
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 the tool as read-only, idempotent, and non-destructive. The description aligns with these, but adds no additional behavioral details such as authentication requirements, rate limits, or what the 'durable result' includes. It does add the use-case of timeout recovery, but that is more about usage than behavior. Since annotations cover the safety profile, a baseline of 3 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose without any fluff. It is front-loaded and easy to scan, with zero 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?
Given the complexity of the tool (3 required parameters, no output schema, and no parameter descriptions), a single sentence is insufficient. It lacks details on what the 'durable result' looks like, how the parameters are used, and any edge cases. The description is too minimal for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three required parameters (marketId, orderControlId, idempotencyKey) with no descriptions, and the schema description coverage is 0%. The description provides no information about these parameters, their purpose, or how they relate to the 'externally signed order submission'. This is a critical gap, as the agent cannot know what identifiers to supply or why they are needed.
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: recovering the durable result for an externally signed order submission after a timeout or restart. This is a specific verb+resource that distinguishes it from sibling tools like strata_order_submit or strata_order_prepare, which handle the submission process itself.
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 a specific trigger context: after a timeout or restart. This gives clear guidance on when to use the tool, but it does not explicitly mention alternatives or when not to use it. The context is sufficient for most scenarios, but a bit more elaboration on how it differs from other order status reads would earn 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully specified. The description adds that it returns rewards season, standings, and owner score, but does not disclose behaviors like pagination or how the limit parameter affects results. Since annotations cover safety, the description's limited additional context earns a middle score.
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, clear sentence with no redundant wording. It efficiently conveys the core functionality without any fluff, earning a perfect score for conciseness.
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 has two optional parameters and no output schema, the description provides a high-level list of results (season, standings, owner score) but lacks details on what the standings include or how the limit affects the response. For a simple read operation with annotations, it is 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 0%, so the description must compensate. It hints at walletAddress's purpose through 'optional owner score' but does not explain the 'limit' parameter at all. While it partially adds meaning, it leaves one parameter entirely undocumented, so it only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads 'the current rewards season, standings, and optional owner score.' It uses a specific verb (read) and identifies the resource, distinguishing it from other listed tools which focus on market data, orders, or referrals. No ambiguity exists.
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 strata_referrals or strata_portfolio. The description only states what it does, leaving the agent to infer usage context. No explicit when-to-use or alternatives are mentioned.
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 is not read-only, is idempotent, is destructive, and acts on an open world. The description adds the nuance that the transaction must be externally signed, but it does not clarify side effects, finality, or error/retry behavior beyond what annotations and schema already communicate. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant restatement of the tool name. Every part contributes meaning: submit, externally signed, prepared transaction, and idempotency key.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter submission tool, the combination of the description, rich schema, strong annotations, minimal overload, and the style of sibling tools is largely sufficient. A bit more detail about expected outcome or post-submission behavior would make it fully complete, but the essential workflow is clear.
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 each parameter, including executionId and signedTransactionBase64, already has a meaningful description. The tool description adds little parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (submit), the resource (an externally signed prepared transaction), and a key constraint (idempotency key). It does not explicitly contrast with sibling submit tools such as strata_order_submit, so differentiation relies partly on the tool name/title rather than the description itself.
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 after a transaction has been prepared and externally signed, and it emphasizes the need for an idempotency key, but it does not explicitly state when to use it versus alternatives like strata_order_submit or strata_execution_prepare. Guidance is inferred rather than stated.
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 the tool read-only, idempotent, and non-destructive, so the description does not need to repeat safety. It adds context by specifying the price is 'customer-facing' and 'current,' which informs expected semantics. However, it does not disclose behavior on invalid inputs, rate limits, or any additional side effects beyond what annotations state. Given the rich annotations, the description provides adequate additional context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no extraneous words. It front-loads the purpose and delivers the core information efficiently. Every word contributes value, and there is no fluff or repetition.
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 tool with strong annotations and a single parameter, the description is complete enough. It clearly states what is read, the scope, and the nature of the price. It does not describe the output format, but given no output schema, this is a minor gap. It adequately covers the essential context for an agent to invoke the tool correctly and interpret the returned price as the reference price for the specified market.
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 0%, so the description must compensate. It adds the meaning 'opaque' to marketId, clarifying it is a system-generated identifier rather than a human-readable name. It also implies a single market ID via 'one opaque market ID,' matching the schema's required field. However, beyond that, it does not elaborate on format, constraints, or units, though the schema already defines the pattern. The addition is minimal but sufficient for a simple one-parameter tool.
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 (read), the resource (current customer-facing reference price), and the scope (one opaque market ID). It distinguishes from siblings like strata_bbo or strata_quote by specifying 'reference price' rather than bid/offer or quoted price. The verb+resource combination is specific and 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. It does not mention when it is appropriate or not, nor does it reference any sibling tools for comparison. The context is implied (e.g., if you need a reference price, use this), but there is no explicit directive or 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?
Annotations already state the tool is read-only, open-world, idempotent, and non-destructive, and the description is consistent with that. It adds useful context by indicating 'live' operations and 'external signing boundaries,' but it does not explain the returned representation, completeness, or any potential dynamic behavior beyond 'live'.
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, front-loaded sentence with a clear verb and a compact enumeration of outputs. Every word contributes; there is no filler 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?
There is no output schema, so the description carries the burden of explaining what the tool reveals, and it does name four relevant output dimensions. It is enough for a 0-parameter discovery call, though a bit more detail on the graph representation would make it fully self-contained.
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 cannot realistically add parameter-level semantics. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a 'Discover' action and names the key outputs: live operations, required capabilities, transition conditions, and external signing boundaries. It differentiates the tool from markets/quote/status siblings, though it overlaps somewhat with strata_capabilities and could more explicitly say 'returns the action graph.'
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 this tool is useful for understanding the Strata action model before executing/preparing actions, but it gives no explicit when-to-use or when-not-to-use guidance. It also does not mention alternatives or when to prefer strata_capabilities instead.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which already cover safety. The description adds value by explaining that this tool can recover 'prepared state' or a 'restart-durable confirmed execution receipt', which hints at idempotent state retrieval without side effects. This adds behavioral 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?
Single concise sentence that is front-loaded with the primary action. No wasted words or redundant 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?
Given the tool's moderate complexity (2 required params, no output schema), the description is minimal but does cover the core purpose. However, with 0% parameter coverage and no output schema, more detail on expected return values or additional context (e.g., typical usage flow after prepare/submit) would improve completeness. It's adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description doesn't explain the parameters beyond the schema patterns. The schema already implies marketId and executionId from the patterns, but the description doesn't add meaning such as how these IDs are obtained or their role in the query. Baseline is 3 because of 0% coverage, but no extra semantic help is provided.
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 ('Recover') and clearly names the resource ('prepared state or a restart-durable confirmed execution receipt'). It distinguishes itself from sibling tools like 'strata_execution_prepare' and 'strata_execution_submit' by indicating this is about querying status after preparation or submission.
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 in recovery scenarios (e.g., after a restart) but does not explicitly state when to use this tool over alternatives like 'strata_order_status' or 'strata_execution_challenge'. No exclusions or alternative tools are named.
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, openWorldHint=true, destructiveHint=false, and the description aligns with those ('Read'). It adds the specific output detail of 'exact claimable reward atoms,' which is useful behavior information. 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?
One concise sentence, front-loaded with the action and resource. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with readOnly annotations, the description adequately conveys the purpose and the specific output (exact claimable reward atoms). It doesn't explain alternatives or error conditions, but given the simplicity, it's mostly 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?
Schema coverage is 0%; description must compensate. It says 'owner' which implies the walletAddress parameter, but it doesn't explicitly state the parameter is the wallet address or provide any additional meaning about what format is expected or how it relates to the referral state. The description is too vague about the parameter.
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 ('Read') on a specific resource ('an owner's referral state') and adds a distinct output detail ('exact claimable reward atoms'). This distinguishes it from sibling tools like strata_referral_claim (write) and strata_referral_link (generate), which 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While the read-only nature implies it is for checking rather than claiming, it does not mention that claiming should be done via strata_referral_claim or that links are created elsewhere. Without exclusions or alternative recommendations, the agent gets no decision-support.
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, idempotentHint, and destructiveHint=false, and the description's 'Read' is consistent with these. It adds the 'currently live' temporal qualifier and the product-level scope, but does not disclose additional behaviors such as data freshness, permissions, or response shape.
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 filler. Every word contributes to identifying what the tool reads.
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 parameterless read-only status tool with strong annotations, the description is largely sufficient. It identifies the key outputs, though the meaning of 'product-level readiness' could be more explicit in 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?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameter semantics. The baseline of 4 applies.
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 'Read' as a specific verb and names two concrete outputs: product-level readiness and the count of live mapped operations. It is clear about the tool's scope, though it does not explicitly contrast with sibling status tools like strata_execution_status or strata_market_making_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?
The description implies this is the tool to call for product-level readiness and live mapped operation counts, but it provides no explicit when-to-use guidance or exclusions. Given many sibling status tools, an agent must infer which status tool to select from the resource names alone.
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 that the tool requests external-signing bytes, indicating this is a preparation step rather than the actual cancellation, and specifies the TWAP must be 'active owned'. This provides useful context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core action. It wastes no words and is appropriately sized for the information it conveys.
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?
With no output schema and four required parameters, the description should explain the expected return (the signing bytes), the complete flow (prepare → sign → submit), and any prerequisites. It only mentions 'active owned TWAP' and the request for bytes, leaving significant gaps about how to use the tool and what happens next.
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 has zero description coverage, and the description only hints at the parameters ('active owned TWAP') without explaining each required field (marketId, ownerWallet, sessionPublicKey, twapId). It does not compensate for the lack of schema descriptions by clarifying parameter purposes or relationships.
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 (request external-signing bytes), the resource (TWAP), and the scope (cancel one active owned TWAP). It distinguishes from sibling tools like strata_twap_prepare (creation) and strata_twap_submit (submission) by explicitly focusing on cancellation.
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 cancellation and mentions 'active owned TWAP', but does not explicitly contrast with alternatives like strata_twap_prepare or strata_twap_submit, nor does it explain the multi-step flow or when to invoke this tool versus the others. It provides some context but lacks clear exclusions or prerequisites.
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 read-only, idempotent, and non-destructive behavior. The description's 'Read' aligns with these traits and adds 'current' to imply real-time data. No additional context about side effects, rate limits, or error conditions is provided, but none are expected for a simple read.
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?
Single, direct sentence with no unnecessary words. The structure is optimal for conveying the tool's purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description sufficiently explains what the tool returns (best bid/ask) and its input. It does not elaborate on output structure or error handling, but this is acceptable given the tool's simplicity and lack 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?
The schema defines marketId with a pattern, and the description clarifies it is a single 'opaque' market ID, adding meaning beyond the raw pattern. It confirms the parameter's role without guessing its semantic value, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the function: reading the current best bid and ask for a specific market. The term 'top of book' and 'current' specify the exact data type, distinguishing it from broader tools like 'strata_book' or 'strata_quote'.
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 prefer this tool over alternatives. The sibling list includes similar tools like 'strata_book' and 'strata_quote', but the description doesn't mention use cases or scenarios where this BBO endpoint is 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds 'bounded' and 'time-bucketed' as useful behavioral context, but it does not disclose return format, pagination, or edge-case 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 a single front-loaded sentence with no filler. Every phrase—'bounded', 'time-bucketed', 'one opaque Strata market ID'—adds meaningful context.
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 schema and annotations are rich, and the description conveys the essential read-only, single-market, candle-aggregation behavior. Since there is no output schema, return format is left implicit, but 'candles' is a standard trading concept and the description covers the core operation well.
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?
With 0% schema description coverage, the phrases 'bounded time-bucketed' and 'one opaque Strata market ID' add meaning: fromMs/toMs delimit the range and resolutionSeconds controls bucket width. However, the description never explicitly maps or explains individual parameters beyond these allusions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Read'), a resource ('candles'), and a clear scope ('one opaque Strata market ID'). This distinguishes it from sibling market-data tools like strata_bbo, strata_trades, or strata_marks.
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 when bounded, time-bucketed candle data for a single market is needed. It provides no explicit when-not-to-use guidance or named alternatives among the many strata_* data tools.
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, and the description is consistent with that (a read-only capability check). The phrase 'currently available' adds a slight dynamic context, but the description does not elaborate on behavior beyond what annotations provide, such as response format or potential caching.
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, clear sentence that immediately conveys the tool's purpose. Every word earns its place 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?
This is a simple capability-discovery tool with no parameters and strong annotations. The description clearly states what it does, and while there is no output schema, the expected result (a list of available features) is reasonably implied. It does not over-explain, making it complete for its 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?
The tool has zero parameters, and the schema is trivially complete. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description adds no unnecessary detail about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('See') and clearly identifies the resource and scope ('which Strata features are currently available to MCP clients'). This distinguishes it from sibling tools like strata_markets and strata_quote, which focus on market data and quotes respectively.
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 does not provide any guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. While the purpose implies discovering capabilities, no explicit context is given.
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 annotation, the description adds specific behavioral details: it is public by wallet address and requires no signature. It also enumerates the data returned (products, live exposure, health, kill state), which is not covered by 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, one sentence that efficiently conveys the tool's purpose and key behavioral traits without unnecessary detail. It is well-structured and easy to read.
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 simplicity of the tool, the description covers essential context: what data is returned and that it is a public, read-only operation. It does not mention error cases, but that is not critical. The absence of an output schema is somewhat compensated by listing the output fields in the description.
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 provides some semantic context for the parameters: it implies that 'walletAddress' identifies the maker and 'marketId' identifies the market. However, it does not explicitly map these names, and the schema itself lacks parameter descriptions, so the description only partially compensates.
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: it retrieves a maker's products, live exposure, health, and kill state in a specific market. It also indicates it is public and requires no signature, which precisely defines the operation.
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 does not explicitly state when to use this tool versus alternatives. It mentions that it is public and requires no signature, which gives some usage context, but it does not differentiate it from other maker-related tools like reputation or order queries.
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 and openWorldHint, and the description builds on that by adding the 'short-lived' nature and the exact output fields expected, including expiry. It does not contradict annotations and adds meaningful behavioral context beyond the structured hints.
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 states the action and enumerates the key return values without wasted words. It is easy to scan and immediately useful for tool selection.
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 helpfully enumerates the quote fields returned. Combined with rich parameter descriptions and safety annotations, the tool is reasonably complete, though the short-lived expiry duration and relationship to sibling quote tools are not explained.
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 schema already thoroughly documents all parameters, including a clarifying note that maximumToleranceBps is not price impact. The description itself adds no parameter-level details, so it does not improve on the schema, but it also does not need to.
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 identifies the action ('Request a short-lived Sonar quote') and the target resource ('Strata market'), and lists concrete return fields. It is distinct from generic market-data tools, but it does not explicitly differentiate itself from sibling quote tools like strata_swap_quote or strata_exact_output_quote.
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: when a short-lived quote for a Strata market is needed. However, it provides no explicit guidance about when not to use it or which sibling quote tool to choose instead, especially since strata_swap_quote and strata_exact_output_quote are available.
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 provide readOnlyHint=false, indicating mutation, but the description does not disclose what side effects occur (e.g., does it invalidate the quote? Are signatures persisted?). It also doesn't mention idempotency or destructiveness beyond annotations. With annotations covering the basic mutability, the description adds minimal context beyond the two-path requirement.
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 packs essential usage information without fluff. It front-loads the primary purpose and then succinctly covers the two authentication paths. No redundant statements.
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 complexity (two distinct paths, 7 parameters, no output schema), the description covers the core usage but lacks some details: what happens if both paths are used, validation behavior, or whether the returned transaction is partially signed. Still, it adequately covers the critical decision points.
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 57% with 7 parameters, and the description adds clarity by associating which parameters belong to which path. For instance, it explicitly pairs quoteId+ownerWallet+sessionPublicKey for one-signature, and challengeId+authorizationSignature for two-step. This goes beyond the schema's individual parameter descriptions, aiding correct parameter selection.
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 that it prepares a quote-bound partially signed transaction, with a specific verb ('Prepare') and resource ('Strata execution'). It distinguishes from siblings like strata_order_prepare and strata_twap_prepare by mentioning 'quote-bound' and the execution context. However, it doesn't explicitly contrast it with other prepare tools, so a slight deduction.
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 two usage paths: one with quoteId+ownerWallet+sessionPublicKey for one-signature, and a legacy two-step path with challengeId+authorizationSignature. It clearly indicates that the challengeId path is still accepted. It does not explicitly state when not to use it, but the two paths give clear context for when to use which parameters.
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, openWorld, idempotent, and non-destructive. The description adds valuable context: data is 'stored' (not computed on the fly), 'genuine', and reported in 'exact USD micros', giving precision and authoritative-source information 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?
One concise, front-loaded sentence communicates the action, subject, and output precision with zero filler. Every word contributes meaning.
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 2-parameter read-only tool with strong annotations and no output schema, this description sufficiently covers the core behavior and return precision. It does not describe the temporal range parameter or output shape, but those are either in the schema or less critical given the tool's simplicity.
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 0%, so the description carries the burden. It does not explain walletAddress or range, relying on the parameter names and enum to convey meaning. The parameter names are somewhat self-explanatory, but the description adds no 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 uses a specific verb ('Read') and resource ('stored account-equity history'), with precision details ('exact USD micros'). This clearly differentiates it from siblings like strata_portfolio, suggesting current snapshot versus historical record.
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 is implied through 'stored account-equity history' – the agent can infer it is the right tool for historical equity data. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternative tools (e.g., strata_portfolio for current equity).
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, so the safety profile is covered. The description adds context about what is read (sealed owner state and external-session readiness) but does not disclose additional behaviors like rate limits or auth requirements. It adds moderate value beyond annotations, hence a 3.
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 zero fluff. It efficiently conveys the core action and key constraint, earning 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 read-only status tool with no output schema and only two flat parameters, the description provides adequate context: it names the data being read and a key constraint. It could elaborate on what 'sealed owner state' means or clarify the role of sessionPublicKey, but given the tool's simplicity and the annotations covering side effects, it is sufficiently 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?
Schema description coverage is 0%, so the description must compensate. It does not explicitly explain walletAddress or sessionPublicKey. The phrase 'optional external-session readiness' alludes to sessionPublicKey, but there is no clear mapping or elaboration. With two parameters and 0% coverage, the description fails to add sufficient 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 states a specific action ('Read') and resource ('sealed owner state' and 'optional external-session readiness'), and clearly distinguishes itself from sibling vault tools by noting it works 'without construction identifiers.' This is a specific verb+resource pair with a clear differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to read vault state without construction identifiers. It does not explicitly name alternative tools, but the 'without construction identifiers' clause provides clear context that this is for cases where those identifiers are absent, differentiating it from other vault operations.
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, idempotentHint, openWorldHint, and non-destructive behavior. The description adds useful context by saying the result is 'durable' and listing possible statuses, but it does not disclose additional behavioral details such as missing-ID handling, staleness, or response format.
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 sentence conveys the tool's purpose and expected outcomes with no filler. The colon-delimited status list is compact 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?
Given low complexity (one parameter, no nested objects, no output schema), the description is sufficiently complete: it states the operation is a read, indicates durability, and lists possible outcomes. It could briefly mention the prerequisite preparationId, but that gap is already penalized in parameter semantics.
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 has no description for preparationId (0% schema description coverage), and the tool description does not explain that this ID comes from the Vault preparation/submission flow or how to obtain it. The pattern provides format but not semantics, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read'), names the resource ('durable outcome of a submitted Vault transaction'), and enumerates the result states ('submitted, confirmed, or failed'). This clearly distinguishes the status-read tool from sibling 'strata_vault_submit', which is the submission 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?
'Read the durable outcome of a submitted Vault transaction' establishes the appropriate context: call this after submission to check persisted status. It does not explicitly name alternatives/exclusions, but the Vault-transaction scope is clear enough for a simple status tool.
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 destructiveHint=false, but the description adds behavioral details such as 'executable' order book and the aggregation of orders into one size per price level. This goes beyond the annotations, providing useful context about what the tool returns and 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?
The description is concise, consisting of two sentences that are front-loaded with the primary action and resource. Every sentence adds value: the first states what is read, the second defines top of book. 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?
For a simple read-only tool with annotations covering safety, the description sufficiently explains the output (bids/asks, one size per level, top of book) without needing extensive detail. It lacks an explicit return format but that is not critical given the simplicity and the presence of annotations.
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 adds minimal value beyond the schema: it calls the market ID 'opaque', but the schema already defines a pattern. The depth parameter is not mentioned in the description, though the schema provides its description. With 50% schema description coverage, the description does not compensate for the marketId lacking an explicit description, but it is adequate given the pattern and required nature.
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 reads the executable order book for a specific market ID, specifying bids and asks with one size per price level and explaining top-of-book. It is distinct from sibling tools like strata_bbo, which likely provides only the best bid/ask, by describing a full order book.
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 obtaining full order book depth but does not explicitly contrast it with alternatives like strata_bbo or strata_trades. It lacks explicit when-to-use or when-not-to-use guidance, though the context suggests it is for depth data as opposed to top-of-book.
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 signal read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond annotations by specifying that reports are redacted and that only confirmed points are included, which informs output expectations. 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 a single front-loaded sentence with no filler. Every word adds value: 'Read', 'owner's', 'redacted', 'bug reports', and 'confirmed points' all contribute to understanding.
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 low-complexity read tool with one parameter and no output schema, the description adequately names the returned content (redacted bug reports and confirmed points) and scoping. It could be slightly richer on what 'confirmed points' means, but the tool's simplicity does not demand much more.
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 has no parameter description (0% coverage), but the parameter name 'walletAddress' is self-explanatory and the description ties it to 'an owner'. This partially compensates, though the description does not explain accepted formats or ownership requirements beyond the schema pattern.
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 ('Read') and clearly identifies the resource: an owner's redacted bug reports and confirmed points. It distinguishes this from the sibling strata_bug_submit by framing it as a read operation.
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 should be used when an owner's bug reports are needed, but it does not explicitly state when to use it over alternatives such as strata_bug_submit, nor when not to use it. The context is clear, but exclusions and alternatives are absent.
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 read-only, idempotent, and non-destructive. The description adds 'anonymized' prints and specifies the data fields (price, size, side, time), providing behavioral details beyond the annotations about the nature of the returned data.
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, front-loaded sentence that conveys the verb (read), the resource (recent anonymized prints), the qualifier (for one opaque market ID), and the output contents (price, size, side, time). No redundant or extraneous 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?
The description sufficiently conveys what the tool does and what returns, but omits details like default limit, pagination, or potential error cases. However, given the lack of an output schema and the simple nature of the operation, it covers the essential aspects adequately.
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 covers `limit` with a description, but `marketId` has no description beyond the pattern. The tool description adds 'one opaque market ID', clarifying that marketId is a hash-like identifier, but doesn't explain how to obtain or interpret it. With 50% schema coverage, the description provides minimal extra value.
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 reads recent anonymized prints, identifies the target resource (a market ID), and lists the return fields (price, size, side, time). This distinguishes it from sibling tools like strata_candles or strata_bbo by its specific focus on trade prints.
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 retrieving recent anonymous trades for a specific market, but does not explicitly contrast with alternatives or state when not to use it. It provides no direct comparison to sibling tools, leaving the agent to infer the scope from the name and 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 only mark readOnly false, but the description adds key behavioral detail: the tool is non-idempotent (first deposit registers session), requires owner funding, and uses opaque IDs. It doesn't mention side effects like fees or reversibility, but the description goes beyond annotations by explaining the session registration nuance, which is valuable for an agent invoking mutation.
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, directly states the core function, and highlights a critical behavioral nuance without fluff. Every word adds value, making it highly efficient.
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 deposit preparation tool, the description covers the essential behavior and the key caveat about session registration. It lacks details about return values or error scenarios, but given the output schema is absent, it is reasonably complete for an agent familiar with the domain.
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 covers parameters but no additional meaning; description doesn't explain the purpose of each field (e.g., why amountAtoms is required, or what sessionPublicKey is used for beyond the first deposit). It mentions the session public key in passing, which adds a hint, but does not fully compensate for no schema descriptions.
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 prepares a Vault deposit and highlights the special behavior of session registration on first deposit, which differentiates it from sibling tools. However, it doesn't explicitly name an alternative or contrast with a specific sibling, so while clear, it doesn't fully leverage sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (exact owner-funded deposit, market and asset IDs) and hints at a prerequisite (first deposit registers session). It lacks explicit exclusions or alternatives, but the context is understandable and sufficient for an agent to decide when to invoke 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 indicate it's a write operation (readOnlyHint false) and not idempotent. The description adds that it performs a registration and mentions that a first deposit 'does this in the same transaction,' implying a combined action. It does not contradict annotations and provides some behavioral context beyond the bare hints.
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—two sentences—and front-loads the main purpose. It avoids unnecessary detail while still conveying the essential functionality and the optional nature of policy fields. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough context for a basic understanding: it explains the purpose, mentions the one-signature nature, and notes that a first deposit can perform setup in the same transaction. However, it lacks detail on the effects of policy fields, potential failure modes, or how this fits with other vault operations, leaving some gaps for an agent that needs fuller context.
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 has 0% description coverage for parameters, and the description only vaguely refers to 'policy fields' without explaining each optional parameter (e.g., marketId, expiresAtMs, spendingLimits). The required parameters (walletAddress, sessionPublicKey) are implicitly clear from 'wallet' and 'session key,' but the optional ones are not semantically explained, leaving the agent to infer their 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 clearly states the tool's function: 'register an external session key for a wallet.' It also highlights a unique value proposition ('one session then trades every market') and distinguishes it from other vault operations by emphasizing the 'one-signature onboarding' aspect.
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 context on when to use the tool ('Only the wallet and the session key are needed; one session then trades every market') and notes that policy fields are optional. However, it does not explicitly contrast it with alternative tools (e.g., strata_vault_deposit) or state when not to use it, though the purpose is fairly 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?
Beyond annotations (readOnly=false, openWorld=true, etc.), the description discloses the single-signature flow, that the tool returns a transaction needing signature, and that an older challenge+signature method is still accepted. This adds meaningful behavioral context not captured by 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?
Two sentences, front-loaded with the core purpose, no redundant phrasing. The key behavioral note about signing is concise and high-value. Every word earns its place.
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 complexity of a multi-step flow (challenge, prepare, submit) and sibling tools, the description gives only minimal context about the overall process. It does not mention that the signed transaction must then be submitted via a submit tool, nor fully explain the two usage modes (place vs cancel). The output schema is absent, so return value details are also missing, but a short prepare tool can suffice if the flow is obvious from the tool name and siblings.
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?
With 0% schema description coverage, the description must compensate. It groups parameters by action ('place fields' vs 'twapId to cancel') and mentions challengeId/authorizationSignature, adding semantic meaning for a few params. However, it leaves most of the 13 parameters undocumented, relying on the schema's patterns/enums, so it only partially compensates.
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 prepares a canonical TWAP transaction, specifying the verb 'prepare' and the resource 'TWAP transaction.' It differentiates from sibling tools by being specifically for TWAP and being the prepare step in the flow, distinct from challenge/submit/cancel 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 direct usage guidance: pass the action itself and sign the returned transaction, with a note that a challengeId+authorizationSignature still works. This implies when to use it (canonical approach) and hints at alternatives (challenge-based), but does not explicitly name other 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?
The description adds valuable context beyond the annotations by specifying 'owner-authorized' (a permission requirement) and outlining the multi-step flow (verification, signing, broadcast), which aligns with the openWorldHint and destructiveHint annotations. This helps an agent understand the real-world side effects and prerequisites that annotations alone do not fully convey.
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, 14-word sentence that is direct, front-loaded, and free of fluff. Every word contributes to the meaning, and the key term 'pause or resume' appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two simple parameters and no output schema, the description covers the essential purpose, authorization, and workflow. It could be slightly more explicit about the return value (e.g., a serialized transaction), but the description is sufficient for an agent to understand when and how to use this tool in the broader process.
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?
With 0% schema description coverage, the description had to compensate by explaining the meaning of 'paused' (true=pause, false=resume) and the role of 'walletAddress' (owner's address), but it does not. An agent is left to infer from the tool name and param names, which is risky for a boolean flag that toggles behavior.
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 ('Prepare') with a clear resource ('owner-authorized pause or resume transaction') and explains the downstream purpose ('for external verification, signing, and broadcast'). This distinguishes it from sibling tools like strata_vault_submit and strata_vault_status, making the tool's role 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 phrase 'for external verification, signing, and broadcast' clearly implies this is a preparation step, not the final submission, and thus belongs earlier in the workflow. While it doesn't explicitly name an alternative tool to use for submission, the context strongly indicates the correct usage pattern without confusion.
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 signal non-read-only behavior, but the description adds meaningful behavioral context: the external signing requirement, the exact payload returned when the signature is omitted, and the hex signature required for submission. This goes beyond what annotations alone provide, though it does not disclose possible side effects of submission.
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 sentences, front-loaded with the core purpose, followed by a clear conditional. Every sentence adds necessary information and there is 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?
The description covers the key two-phase interaction model and the role of the signature. There is no output schema, but the description implies what is returned in prepare mode ('the exact payload'). It does not explain submission outcomes or error cases, but for a simple 3-parameter tool this is largely 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?
Schema description coverage is 0%, so the description must compensate. It explains the role of ownerWallet and authorizationSignature in the signing/submission flow, but it does not explain the 'message' parameter's content or expected format beyond the schema constraints. Partial compensation only.
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: 'Prepare or submit a bug report.' It also clearly distinguishes the tool from siblings like strata_bugs by indicating this tool handles submission rather than just listing/viewing bugs. The two-mode framing makes 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance for the two modes: omit authorizationSignature to prepare/sign, or provide the hex signature to submit. It does not explicitly name alternative tools or exclusions, but the conditional flow is specific enough for an agent to know when to use each path.
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 (readOnly=false, idempotent=true), the description adds valuable behavioral details: Strata verifies the transaction is exactly the prepared one, pays network fee/rent when sponsored, recovers costs later from deposits as network_cost_atoms, and notes the owner needs no SOL/RPC. It also clarifies idempotency per idempotencyKey. 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?
Three sentences pack a lot of information without verbosity. The front-loaded first sentence states the purpose and transaction types, and subsequent sentences add fee, sponsorship, idempotency, and outcome-reading context. Slightly dense but earned its length.
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 submit tool with no output schema, the description covers key contextual points: when to use, fee handling, no SOL/RPC requirement, idempotency, and where to read the outcome (strata_vault_submission). It does not mention failure modes or return values, but the sibling reference mitigates that gap. Overall complete for an integration point.
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 67%, and the description does not add much per-parameter detail beyond what the schema provides. It reinforces that idempotency is tied to idempotencyKey and that signedTransactionBase64 is the prepared transaction plus owner signature, but it does not explain idempotencyKey format or any constraints. Since coverage is moderate, this is an adequate but not exceptional 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-resource pairing: 'Submit an owner-signed prepared Vault transaction' and enumerates transaction types (setup, deposit, withdrawal, session, policy, pause). This clearly distinguishes it from sibling tools like strata_vault_setup or strata_vault_submission by focusing on the submission step of an already-prepared, owner-signed transaction.
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 usage context explicit: it is for owner-signed prepared Vault transactions, and it mentions that the owner needs no SOL or RPC because Strata handles fees. It also gives an explicit alternative: 'read the outcome with strata_vault_submission.' It does not state when NOT to use it, but the context is sufficiently 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond this by disclosing that the autonomy level is the user's, set out-of-band (Agents page or the MCP's own env) and never mutable by an agent — context about governance and modification authority that annotations cannot convey. It also enumerates the level values (ask / limits / instant), enriching the behavioral 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?
Two sentences, zero waste. The first sentence front-loads the purpose with a concrete verb and enumerates exactly what's returned; the second sentence adds a critical behavioral constraint. Every clause earns its place, with no redundancy against the annotations.
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?
Although there is no output schema, the description covers the essential surface: the return contents (level enum values, ceilings, change instructions) and the read-only nature. For a simple 0-parameter read tool with strong annotations, this is nearly complete — it could marginally benefit from describing the exact response structure, but the description suffices for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, the baseline is 4 per the rubric. The description does not discuss parameters (correctly, since there are none) but instead describes the semantic output: the autonomy level with its three possible values, USD ceilings, and how to change the level. This is the appropriate use of description space for a no-parameter configuration read.
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 ('Read') with a clear resource (autonomy level, USD ceilings), and states exactly what information is returned (level values ask/limits/instant, ceilings, change instructions). It clearly distinguishes itself from all sibling tools, which deal with capabilities, status, execution, or market data — none of which cover the session autonomy configuration.
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 opening phrase 'Read how much this MCP may finish by itself' gives clear context for when to call this tool (when the agent needs to understand its autonomy ceiling and spending limits). The read-only caveat with 'never by an agent' effectively tells the agent this is a query-only operation, though it never names an explicit alternative tool for changing settings (since none exists — that's done out-of-band).
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 discloses key behavioral aspects: the quote is short-lived, fails closed if tolerance is exceeded, and returns an input amount (amount_in_atoms). It also clarifies the interaction between minimum_output_atoms and maximumToleranceBps, adding value beyond the read-only annotation.
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 the main purpose, and efficiently covers the key details without unnecessary fluff. It is well-structured and 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?
The description adequately covers the tool's function, parameters, and execution flow. It mentions the returned amount_in_atoms and the reuse of the quote_id flow, but does not enumerate the full response structure since no output schema is provided. This is acceptable given the 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 schema already provides detailed descriptions for each parameter. The tool description mostly reiterates these points (e.g., tolerance behavior) and adds minimal new context about route inversion. The added value is marginal since schema coverage is 100%.
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: requesting a short-lived quote for an exact output amount and inverting the route to return the required input. It includes a concrete example and distinguishes the exact-output behavior from other quote 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 explains how to use the quote (execute with the same quote_id flow as strata_quote) and implies the appropriate scenario (when you know the desired output). However, it does not explicitly contrast with exact-input quote tools or state when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds behavioral value by explicitly stating 'No signature, no session key' and 'public read', which are auth-related details not covered by annotations. It also clarifies the scope ('across every live market') and data format ('exact USD'), enhancing transparency 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 sentences, front-loaded with the core purpose ('The whole account in one public read, by wallet address') followed by a clear list of contents. It is concise, with zero filler, and every clause contributes to understanding the tool's scope and constraints.
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 returns a comprehensive portfolio snapshot without an output schema, the description lists the types of data returned (balances, positions, orders, fills) and specifies 'exact USD' for balances. It also sets expectations by mentioning 'across every live market'. It could optionally clarify data freshness or size limits, but for a read-only portfolio endpoint, 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?
There is only one parameter, walletAddress, with a schema pattern but no description coverage (0%). The description references 'by wallet address' but adds little semantic meaning beyond what the parameter name and pattern already convey. It does not explain the address format or requirements, but the pattern is self-explanatory for those familiar with crypto addresses. Given the simplicity, the description is adequate but not value-adding.
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: 'The whole account in one public read, by wallet address' and enumerates the specific contents (balances, positions, open orders, recent fills) across all live markets. It distinguishes itself from siblings by emphasizing 'one public read' and 'no market selection', which differentiates it from market-specific tools like strata_bbo or strata_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: when you need a complete snapshot of an account without filtering by market. It does not explicitly name alternatives or state when not to use, but the phrase 'no market selection' implies it's not for granular per-market queries. The sibling tools like strata_order_status or strata_execution_status suggest alternatives exists, but the guidance is 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, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable context: the data is public by wallet address and requires no signature, and enumerates the specific reputation aspects returned. This enriches the agent's understanding 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?
One concise sentence that front-loads the core purpose (reliability, participation, tier, signed-quote eligibility) and adds key context (public, no signature). No filler or redundant 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 read-only tool with no output schema, the description sufficiently explains what the tool does, what data it returns, and the access requirement (public, no signature). It covers both parameters implicitly and is complete for the agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly maps both parameters to their purpose: 'market' for marketId and 'wallet address' for walletAddress. It clarifies that access is public and no signature is needed, adding meaning beyond the schema's type/pattern constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a maker's reputation metrics (reliability, participation, tier, signed-quote eligibility) for a single market. It is specific about the resource (maker reputation) and scope (one market), distinguishing it from siblings like strata_market_making_status which focus on status.
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 indicates the tool is read-only and public (no signature), which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives, though the clear scope (maker reputation in a market) provides context for selection.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alsk1992/strata-mcp'

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