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

Goes well beyond the annotations with replacement semantics ('replaces the stored list for that key in one write'), empty-array consequences ('stores an allowlist that authorizes no wallet' leading to reason unauthorized_wallet), dev-wallet rejection behavior, auth requirements, error codes, and billing ('does not consume a score and is never billed'). None of this is covered by readOnlyHint/idempotentHint/destructiveHint.

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

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

Front-loaded with the core action and dense with operational detail, though a few sentences restate the schema ('allowed_wallets is required', 'an empty array stores...'). Long but nearly every sentence carries routing or safety value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description enumerates the return fields (key_id, key_prefix, allowed_wallets, updated_at), covers auth paths, error responses, edge cases like new keys starting unset, and warns against passing private keys. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds constraints the schema lacks: at most 32 addresses and the downstream block/unverified behavior for empty or unset lists. It repeats some schema content (empty array authorizes none), which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb, resource, and scope: 'Store the 0x wallets this sg_live_ key is allowed to spend from.' It is immediately distinguishable from score_spend, get_api_key, and get_quota because it names the store-once semantics and explicitly says it is not for approving payments.

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

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

Gives explicit when ('when an operator names those wallets, once, not on every spend'), when-not ('not to approve a payment'), the prerequisite ordering ('score_spend still has to run before any transfer'), and the alternative for anonymous/bundle callers ('pass allowed_wallets on score_spend instead').

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