VEYA

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about side effects, auth requirements, failure modes, or whether the operation is read-only. "Return" weakly implies a read, but the schema's own warning ("Guest JWT is not a write credential") shows there is relevant auth nuance the description never surfaces.

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?

A single front-loaded clause with zero filler; nothing could be trimmed without losing meaning.

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?

With no output schema and no annotations, the description should characterize the return value, but "the wallet" leaves the shape (address string vs. object) unspecified. Parameter behavior is fully covered by the schema, so the gap is confined to return semantics and auth nuance.

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%, including the optional sessionToken and its "Use listing only. Prefer apiKey" guidance, so the baseline is 3. The description adds no syntax, format, or precedence detail beyond what the schema already states.

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?

The description names a specific verb ("Return") and a specific resource ("the wallet bound to a product API key"), so an agent can tell what comes back. It does not reference any sibling tool, so differentiation from the other veya_* lookups is left to inference.

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?

There is no statement of when to use this tool versus alternatives, nor any prerequisite or exclusion. The only usage signal is the implicit pairing of "product API key" with the apiKey parameter, which the schema already covers.

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

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

With no annotations, the description carries the full behavioral burden. 'From YOUR wallet' implies the operation is signed and gas-paid by the caller's own key, but nothing states that this is an irreversible on-chain write, what permissions/API key are required, or what happens on failure. The key behavioral facts are left to inference.

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?

It is a single, front-loaded sentence with no filler, which is good. But the terseness tips into cryptic phrasing ('YOUR wallet') rather than earning its place with useful detail.

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?

This is a 5-parameter on-chain write with no annotations, no output schema, and 40% parameter coverage. For that complexity the description is far too thin: it omits prerequisites, side effects, and the meaning of three required hash/environment arguments.

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 coverage is only 40%: apiKey and payerPrivateKey are documented in the schema, but identityHashHex, executionHashHex, and environmentUuidHex have no descriptions anywhere. The description mentions no parameter names or formats, so it fails to compensate for the coverage gap on three required fields.

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?

The description gives a concrete verb and resource: it links a PQ identity hash to an execution hash on the Veya.sol contract. That is specific enough to know what the tool does. However, it offers no differentiation from close siblings such as veya_anchor_proof or veya_attest_execution, which an agent could easily confuse it with.

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?

There is no guidance on when to use this versus veya_anchor_proof, veya_attest_execution, or veya_register_pq_onchain, and no stated prerequisites. The phrase 'from YOUR wallet' hints at a wallet-signed path but does not define the condition that selects this tool.

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

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

With no annotations, the description carries the full burden and does disclose the important behavioral trait that the caller's own wallet pays (payerPrivateKey, gas). It does not state irreversibility of the on-chain anchor, what permissions are required, or what is returned, so the disclosure is partial.

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?

Two tight sentences, zero filler, with the wallet/credential model and the relayer exclusion front-loaded. Every clause earns its place.

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?

For a 6-parameter on-chain write with no annotations and no output schema, the description covers the credential model but omits gas/irreversibility implications, environmentId semantics, and any sense of the result. Adequate but with clear gaps.

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 50%, with apiKey/sessionToken/payerPrivateKey documented but label, content, and environmentId bare. The description reinforces which two credentials matter (apiKey + payerPrivateKey), which adds some meaning, but it does not explain label/content/environmentId beyond the schema.

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 ('Anchor') and resource ('a content proof on Veya.sol') and clarifies the credential path (your wallet vs. the hosted relayer), which distinguishes it from sibling anchoring tools like veya_anchor_pq_attestation. It does not name a specific sibling, so differentiation requires the reader to infer.

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?

'Does not use the hosted relayer' implies the selection condition (self-custodied anchoring vs. a relayer-backed path), but no alternative tool is named and no when-not-to-use guidance is given. Usage must be inferred from the credential mention.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose that the tool targets the /health endpoint and covers fleet status, which tells the agent this is a read-only diagnostic. It says nothing about authentication, rate limits, or how failures are reported, which for a 0-parameter monitoring endpoint is a modest but real gap.

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?

A single front-loaded sentence that names the verb, the resource, the host, and the coverage of the check. Nothing is redundant and nothing needs to be trimmed.

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?

With no parameters, no annotations, and no output schema, the definition is nearly complete for a simple diagnostic endpoint — the agent knows what is checked and where. It could still say what the health response includes or whether it requires network reachability, which is why it falls short of 5.

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?

The tool takes zero parameters, so there are no parameter semantics for the description to explain; the baseline for a no-parameter tool is 4. The parenthetical host reference is harmless context rather than parameter documentation.

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?

The description states a specific verb and resource: 'Check the VEYA API /health status (api.veyanet.tech)', and adds scope detail ('including fleet status'). It does not, however, differentiate itself from related siblings such as veya_public_stats or veya_writes_status, leaving the agent to infer the boundary.

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?

Usage is only implied by the nature of a health check; there is no explicit 'use when' statement, no mention of when to prefer veya_public_stats or veya_writes_status, and no stated prerequisites (e.g. network/auth requirements). An agent can guess the intent but gets no routing guidance.

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

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

Annotations are absent, so the description carries the full disclosure burden. It implies an on-chain write from the user's wallet but says nothing about gas payment, irreversibility, required credentials, or what happens on failure; the only write-permission hint lives in the schema, not the description.

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?

It is a single tight sentence with no filler, so nothing is wasted. But the brevity reflects under-specification rather than disciplined conciseness, leaving essential scope and mechanics unstated.

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?

For a five-parameter on-chain write tool with no annotations, no output schema, and only 40% schema coverage, the description is materially incomplete. An agent lacks the prerequisites, alternatives, and parameter semantics needed to invoke it confidently.

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 coverage is only 40%, so the description should compensate but does not. The phrase 'ML-DSA bytes' loosely maps to mldsaSigHex, but environmentUuidHex, blake3HashHex, apiKey, and payerPrivateKey receive no explanation of their role in this specific call.

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?

Names a specific function (attestExecution) on a specific contract (Veya.sol) and indicates the wallet and signature inputs, which is more than a tautology. However, it never explains what 'attesting an execution' actually means and does not clearly distinguish itself from close siblings like veya_anchor_pq_attestation or veya_anchor_proof.

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?

No when-to-use, when-not-to-use, or alternative-tool guidance is present. With siblings such as veya_anchor_pq_attestation, veya_prove, and veya_sealed_execute available, the agent is left to guess when this tool is the correct choice.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses one real trait — the call is policy gated — and the schema notes that a guest JWT is not a write credential. Beyond that it says nothing about side effects on the invoked tool, failure modes when policy denies, or whether arguments are forwarded verbatim.

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?

One short, front-loaded sentence with no filler, which is structurally clean. However, it is under-specified rather than genuinely concise — the brevity comes at the cost of the information an agent needs to invoke it.

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?

For a 6-parameter dispatcher with a nested free-form 'arguments' object, no annotations, no output schema and 33% coverage, the description is far too thin. It omits what the tool returns, how nested arguments are routed, and what the policy gate actually enforces.

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 only 33%: apiKey and sessionToken are documented, but toolName, arguments, environmentId and agentId are bare. The description adds nothing — crucially it never explains that 'arguments' must match the target tool's own argument schema, which is the single most important parameter semantic for a dispatcher.

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?

The description gives a verb ('Invoke') and a resource ('a Boundnet / coordination tool via product API'), so the agent knows this is a dispatcher for other tools. But 'Boundnet / coordination tool' is unexplained jargon and it never says which tools are invocable or how this differs from calling siblings like veya_run_consensus or veya_seal_decision directly. Purpose is identifiable but not sharply distinguished from siblings.

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?

Only the parenthetical '(policy gated)' hints at a precondition. There is no guidance on when to route through this generic invoke versus calling the concrete sibling tool directly, no mention of what policy must be satisfied, and no exclusions. The agent must infer all routing decisions.

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

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

With no annotations, the description carries the full burden. It usefully discloses an auth requirement ('Needs a product API key') and that behavior matches the successor's validator list, but says nothing about side effects, return values, or cost of invocation.

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?

Three terse fragments with the deprecation warning front-loaded and zero filler. It could be marginally fuller sentences, but nothing is wasted.

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?

For a deprecated redirect the essentials are present: where to go instead and the API-key requirement. But with no annotations, no output schema, and an undocumented required taskId plus nested payload, an agent still lacks enough to invoke it correctly if it ever must.

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 coverage is 0%, so all three parameters depend on the description. It covers only apiKey ('Needs a product API key'); taskId and the nested payload object — the one required input — are left entirely undocumented in both schema and prose.

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?

The description never states what the tool actually does — 'consensus' and 'server validator list' are referenced but not explained. Its clearest signal is the deprecation redirect to veya_run_consensus, which does distinguish it from that sibling, but the core verb+resource is only inferable from the tool name.

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?

'Deprecated: use veya_run_consensus' is an explicit, unambiguous alternative with an implied when-not-to-use condition. It stops short of saying whether any scenario still warrants this legacy tool, but for a deprecation stub the routing guidance is strong.

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

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

With no annotations, the description carries the full burden, but it does disclose a genuinely useful trait: this is an eth_call, i.e. a read-only simulation with no gas cost, signing, or state mutation. That is real value. It stops short of stating which chain/network is queried, whether the read reflects finalized state, or what happens for a missing commitment.

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?

A single terse clause with no filler; the essential information leads. It is arguably under-specified rather than wasteful, but structurally it is clean.

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?

No output schema, no annotations, and a parameter with zero schema documentation. For an on-chain read tool the agent still lacks the return shape (boolean? address? revert on missing?) and the target chain, so the definition is not self-sufficient for correct invocation.

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 0%, and the single parameter is only constrained by minLength 64. The description compensates partially by tying the argument to the ABI's bytes32 digest, which implies a 32-byte value. It does not specify encoding (hex vs base64, 0x prefix, casing), leaving real ambiguity for a raw bytes32 argument.

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?

The description names a concrete operation - an eth_call to Veya.sol's commitments(bytes32) mapping - so an agent can tell it touches the on-chain commitment registry. But it never states the purpose in plain terms (checking whether a commitment exists for a digest) and gives no differentiation from siblings like veya_verify_commitment_onchain or veya_store_commitment, which an agent would need to choose between.

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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives. The nearest sibling, veya_verify_commitment_onchain, is indistinguishable from this tool on the basis of the description alone.

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

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

With no annotations provided, the description carries the entire behavioral burden, and it does well: it discloses the non-transactional/non-gas nature of the operation, the authentication requirement (guests and non-keys are refused), name-validation policy, and the persistence/default behavior of the type field. It omits return shape, uniqueness/duplicate-name behavior, and idempotency, which are meaningful gaps for a creation tool.

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?

Six short sentences, front-loaded with the action before the constraints, and nearly every sentence carries usable information. It is slightly choppy and the trailing name rule is awkwardly phrased, but there is no filler.

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?

For a four-parameter mutation tool with no annotations and no output schema, the description covers cost, auth, and naming rules well, but says nothing about what is returned (e.g., an environment identifier) or what happens on duplicate/invalid names beyond rejection. An agent can probably invoke it correctly, but not predict or handle the result.

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 50% — apiKey and sessionToken are documented in the schema, but name and type are bare. The description compensates by explaining that type defaults to research when omitted and by spelling out the name policy (real name of at least 6 characters, or a VEYA prefix, with rejected test-like prefixes). That said, the stated 6-character minimum conflicts with the schema's minLength of 1, adding ambiguity rather than clarity on that one point.

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?

Opens with a specific verb+resource: "Create a workspace in the product API." That is unambiguous about what the call does at the domain level. It does not, however, differentiate itself from close siblings such as veya_register_environment or veya_list_environments, and it freely swaps "workspace" for the tool's "environment" terminology, which could make an agent pause when both tools are visible.

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 concrete context for use: it does not spend gas and sends no transaction, guests and non-key callers are refused, and certain name prefixes (test, demo, tmp, sandbox, e2e) are rejected. These are real preconditions an agent needs before calling. There is no explicit statement of when to prefer this over a sibling like veya_register_environment, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full behavioral burden and does real work: it discloses that the call spends no gas and sends no transaction, that omitting allowedTools yields an agent that cannot call tools, and that type defaults to 'coordination'. Gaps remain on authentication requirements and failure behavior, but the disclosed traits are non-obvious and useful.

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?

Four short sentences, front-loaded with the purpose, then constraints, then parameter defaults. Little waste, though the gas/transaction sentence could be tightened.

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?

For a mutation tool with no annotations, no output schema, and a nested permissionConfig object, the description covers key constraints but omits auth requirements (apiKey vs sessionToken) and what a successful call returns. Adequate but with clear gaps.

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 coverage is only 33%, so the description must compensate. It adds meaning for permissionConfig.allowedTools and the type default, but leaves agentKind and environmentId (the sole required field) unexplained. Partial compensation only.

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 and resource: 'Create an agent in a workspace.' An agent can distinguish this from list/read/register siblings (veya_list_agents, veya_register_environment). No explicit sibling callout, but the core action is unambiguous.

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?

The description describes constraints on the created agent but never says when to choose this tool over adjacent ones such as veya_create_environment or veya_register_environment. No when-to-use/when-not guidance is provided, leaving selection to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It mentions the subject matter but does not state whether the tool is read-only, safe to call repeatedly, requires authentication, or what side effects (if any) it has.

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?

The description is very short and front-loads the topic, but it is a sentence fragment with a colon rather than a complete, well-structured statement. It is concise but under-specified, similar to a minimal label rather than a usable tool description.

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?

For a zero-parameter info tool with no output schema, the description gives only a high-level topic. It does not explain what the returned service info contains or when this tool is the right choice, which leaves an agent with gaps for correct invocation.

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?

The tool takes zero parameters, so there are no parameter semantics to explain. Per the rubric, a zero-parameter tool receives a baseline of 4 even without description-level parameter detail.

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?

The description names the subject matter (AES-256-GCM sealed execution and the selected settlement profile) but uses a noun fragment rather than a clear verb+resource statement. It does not distinguish this tool from siblings like veya_public_stats or veya_api_health, leaving the agent to infer that it returns descriptive service information.

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?

There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states what information is available, not when an agent should call it.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses essentially nothing: no confirmation that it is a read-only operation, no auth requirement (the schema implies apiKey/sessionToken but not that they are optional for reads), and no note on what happens when the id is unknown. By contrast, sibling parameters already carry credential semantics that the description ignores.

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?

Six words, front-loaded with the verb and resource, with zero preamble or filler. It is efficient rather than bloated, though the extreme brevity arguably costs more in missing context than it saves in tokens.

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?

For a tool with no annotations, no output schema, and a credential-bearing parameter set, the description should clarify the read-only nature, the auth model, and at least the notion of what an 'environment' returns. None of that is present, leaving the agent dependent on sibling conventions.

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 coverage is 67%, and the apiKey/sessionToken parameters are documented in the schema itself, so the schema does the heavy lifting. 'By id' weakly signals that environmentId is the lookup key, but the description adds no format, source, or constraint information beyond what the schema already shows.

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?

The description names a specific verb and resource ('Get one environment by id'), which separates it from veya_list_environments at a glance. It does not, however, differentiate itself from the other single-environment readers in the sibling set (veya_read_environment_onchain, veya_public_get_agent-style lookups), so it stops short of a 5.

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

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

There is no when-to-use guidance, no statement of prerequisites, and no routing to alternatives such as veya_list_environments for enumeration or veya_read_environment_onchain for on-chain state. The agent must infer selection entirely from the name.

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

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

With no annotations, the description carries the full burden. It usefully discloses the permission ceiling ('cannot mint API keys or write from MCP'), but says nothing about session lifetime, how the session is subsequently used, or what the call returns.

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?

Two compact sentences, with the purpose front-loaded and the restriction immediately after. No filler, though the parenthetical is slightly clipped in phrasing.

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?

For a zero-param session-bootstrap tool with no output schema, the definition covers what the tool is and its limits, but omits the practical mechanics an agent would want: whether a token is returned, its lifetime, and how to use it in later calls.

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?

The tool takes zero parameters, so the schema and description have no parameter semantics to reconcile. Baseline 4 applies.

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 and resource ('Create a guest session') and distinguishes itself from account-bearing siblings like veya_account by the 'guest' qualifier. 'On the product API' is slightly vague about which surface, but the core purpose is unambiguous.

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?

The parenthetical '(Use listing only)' and the note that guests cannot write from MCP give an implicit when-to-use boundary, but no alternative tool (e.g. veya_account) is named for the cases where a guest session is insufficient. Usage is implied rather than routed.

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

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

No annotations are provided, so the description carries the full disclosure burden. It reveals the output encoding (hex digest) which is useful given there is no output schema, but says nothing about determinism, input encoding (UTF-8 text vs. bytes vs. pre-hashed data), or whether the operation is pure/side-effect free.

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?

A single front-loaded sentence with no filler; size is appropriate for a one-parameter utility. It is terse rather than bloated, though the terseness edges into under-specification.

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?

For a simple hash helper this is nearly adequate, but with no annotations, no output schema, and an undescribed input parameter, the description should at minimum pin down input encoding and confirm determinism. Those gaps are the ones most likely to cause a miscall.

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?

The single parameter 'data' has 0% schema description coverage and the description adds nothing about it. An agent cannot tell whether 'data' is literal text to be UTF-8 encoded, a hex string, or raw bytes — a material ambiguity for a hashing tool.

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 ('Compute') and resource ('BLAKE3 hex digest'), so an agent knows exactly what operation it performs. It does not, however, explicitly distinguish itself from the commitment-related siblings (veya_store_commitment, veya_verify_commitment_onchain) that the 'commitment helper' tag alludes to.

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?

The parenthetical 'commitment helper' hints at a use case but gives no when-to-use condition, no prerequisites, and no named alternatives among the many commitment/proof siblings. An agent must infer the role from the tag alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Nullify" implies mutation, but the description does not disclose permanence, reversibility, permission requirements, side effects, or response behavior.

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?

It is a single front-loaded sentence with no wasted words. The structure is efficient, though extremely minimal for a mutation tool.

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?

With no annotations, no output schema, and 0% schema description coverage, this one-sentence description is incomplete. It omits environmentId semantics and key behavioral details needed for safe invocation.

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 0% for 3 parameters. The description implies "one memory row" maps to the id and "this API key" maps to apiKey, but it never explains the required environmentId or any parameter format.

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?

The description states a specific verb and resource: "Nullify one memory row," plus ownership scope "owned by this API key." It is clear enough to distinguish from read/store/list memory tools, though it does not name a sibling explicitly.

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?

There is no guidance on when to use this tool versus alternatives such as veya_read_memory, veya_store_memory, or veya_list_api_memory. It also does not state prerequisites or when invalidation is appropriate.

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

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

No annotations are provided, so the description carries the full burden, and it discloses nothing about authentication requirements, pagination, result limits, or ordering. The only auth context lives in the schema properties (apiKey vs sessionToken), which the description does not reinforce or explain.

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?

A single terse sentence with no wasted words and the resource front-loaded, but it is under-specified rather than genuinely concise; there is little structure beyond the bare statement.

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?

For a list tool with no output schema, the description should at least indicate the auth path (apiKey preferred, guest JWT limited to listing) and how it differs from the public listing sibling. It omits both, leaving the agent to infer everything from the schema.

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 coverage is 67% – apiKey and sessionToken are documented in the schema, while environmentId (the required param) is undocumented but semantically obvious. The description adds no parameter meaning beyond what the schema already provides, so the baseline 3 applies.

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 clear verb+resource (list agents) scoped to an environment. However, it gives no differentiation from the sibling veya_public_list_agents, so an agent cannot tell from the description which listing tool is the private/authenticated one.

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?

There is no guidance on when to use this versus veya_public_list_agents, veya_public_get_agent, or veya_list_environments. The environment requirement is implicit in the name only.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about authentication requirements, rate limits, pagination, or what the returned entries contain. It only repeats that access is 'via product API', which adds little beyond the tool name.

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?

A single short sentence with no filler and the resource and scope front-loaded. It is efficient, though its brevity borders on under-specification rather than true concision.

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?

With no output schema and no annotations, the description needs to explain authentication mode selection, the meaning of the scope enum, and roughly what a listing returns. None of that is present, so an agent lacks enough to call this correctly beyond the required environmentId.

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 coverage is 50%; apiKey and sessionToken are documented in the schema, but the required environmentId and the scope enum (environment/agent/session) have no descriptions. The description's 'for an environment' hints at environmentId but leaves the important scope semantics completely unexplained.

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?

The description uses a specific verb ('List') and resource ('memory entries') scoped to an environment via the product API, so an agent can tell it apart from mutating siblings like veya_store_memory or veya_invalidate_memory. It does not explicitly contrast with veya_read_memory, however, leaving the list-vs-single-read distinction to inference.

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?

There is no statement of when to use this tool versus alternatives such as veya_read_memory, veya_list_executions, or veya_list_agents, and no guidance on choosing between apiKey and sessionToken despite the schema hinting that sessionToken is listing-only. The usage context is only implied by the phrase 'for an environment'.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one real behavioral trait — a guest JWT yields a reduced result set (showcase / Use scope only), which is genuine scoping information beyond the schema. It says nothing about what happens with an invalid/absent credential, pagination, or result shape.

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?

A single front-loaded sentence with the resource and credential condition stated immediately; no filler. It is arguably too terse for a tool whose name does not reveal its credential model, but nothing in it is wasted.

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?

With no annotations and no output schema, the description is the only behavioral source, and it covers credential scope but not what a returned environment looks like, ordering, or pagination. Adequate but with clear gaps for a two-parameter listing tool with an unusual dual-credential model.

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 coverage is 100%, so the schema already documents both apiKey and sessionToken, including the 'prefer apiKey' guidance. The description's 'guest JWT sees showcase / Use scope only' restates and slightly sharpens the sessionToken semantics, which is marginal added value over structured data.

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 (List) and resource (environments) scoped to a product API key, which is clear enough to distinguish it from mutators like veya_create_environment or veya_register_environment. However it never names or contrasts with the read siblings veya_get_environment or veya_read_environment_onchain, so sibling differentiation is left to inference.

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?

The parenthetical implies credential selection (product API key vs guest JWT) and warns that a guest JWT only sees showcase/Use scope, which is useful context. There is no explicit when-to-use-this-vs-alternatives statement, and the choice between this, veya_get_environment and veya_read_environment_onchain is unaddressed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says 'via product API' but does not disclose read-only semantics, authentication requirements beyond the schema, pagination behavior, result limits, or failure behavior.

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?

The description is a single front-loaded sentence with no filler. Every phrase contributes to identifying the operation, even though terseness leaves gaps addressed in other dimensions.

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?

For a simple list tool, the description plus schema cover the environment scope and authentication basics. However, with no annotations and no output schema, the description omits pagination, result shape, and filtering expectations that an agent may need.

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 67%: apiKey and sessionToken are documented in the schema, while environmentId has no schema description. The description only implies the required environment scope ('for an environment') and adds no syntax, format, or relationship detail beyond what the schema provides.

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 ('List') and resource ('executions') scoped to 'an environment' via product API. It is clear, but it does not explicitly distinguish this tool from sibling retrieval or listing tools such as veya_public_get_execution or other list endpoints.

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?

The description gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The only usage signal is the implied need to list executions for a given environment, with no prerequisites or routing context.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only listing, but never states the auth requirement, whether results are scoped/paginated, or what a 'proof anchor' record contains.

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?

A single short sentence with the resource front-loaded and no filler. It is efficient, though terseness comes at the cost of the undefined 'Use-mode' term and missing scope details.

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?

With no annotations and no output schema, the description must explain return shape and auth behavior; it does neither. It also omits pagination and what 'the account' means for a guest JWT caller, leaving key gaps for a listing tool.

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 coverage is 100% and both parameters (apiKey, sessionToken) are fully described in the schema, including the guest-JWT-vs-apiKey distinction. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 clear verb and resource ('List ... proof anchors') scoped to 'the account', which is better than a tautology. However, 'Use-mode' is undefined jargon and the description does nothing to distinguish this from siblings like veya_anchor_proof, veya_verify_proof_api, or veya_list_executions.

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?

The description gives no when-to-use guidance, no prerequisites, and no alternatives. A sibling (veya_anchor_proof) creates anchors while this one lists them, but that relationship is left entirely to inference.

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

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

No annotations are present, so the description carries the full behavioral disclosure burden. It does not state whether the operation is read-only, whether it performs a live network call, what happens on failure, or any auth/rate-limit constraints.

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?

A single front-loaded sentence with no filler. It communicates the action and the key outputs immediately, which is appropriate for a zero-parameter tool.

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 the low complexity (no parameters, no output schema), naming the returned fields is helpful. However, with no annotations and no output schema, the description should still disclose basic behavioral traits such as read-only nature and failure behavior.

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?

The tool takes zero parameters, which sets the baseline at 4. The description lists example return values ('chain id, block, contract') but does not document parameters, appropriately so for a parameterless tool.

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 action ('Ping') and target ('Robinhood Chain RPC') plus the information returned (chain id, block, contract). It is clear what the tool does, though it does not explicitly differentiate itself from the sibling `veya_api_health`.

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?

Provides no guidance on when to use this tool versus alternatives such as `veya_api_health`, nor any prerequisites or exclusions. The ping-style name implies a health check, but that is left to inference.

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

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

With no annotations provided, the description must carry the full behavioral burden. It does not say whether the operation is read-only/pure, whether the fingerprint is deterministic, what encoding or length the fingerprint output takes, or what happens with malformed key input — all relevant for a crypto primitive.

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?

It is a single sentence fragment with zero padding, so it is maximally concise. However, it is under-specified rather than well-structured, and lacks an explicit verb to anchor the operation.

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?

For a cryptographic tool with no annotations and no output schema, the description should at minimum state the return format and that the call has no side effects. Neither is covered, leaving meaningful gaps for correct invocation.

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 0%, so the description must compensate. It partially does by identifying the sole input as an ML-DSA public key in hex, but adds no detail on expected length, curve/parameter-set variants, or format validation beyond the schema's minLength.

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?

The description names a specific operation (BLAKE3 fingerprint) on a specific resource (an ML-DSA public key hex), which is far more precise than the bare name. It implicitly separates the tool from the generic sibling veya_hash_blake3 by tying it to the ML-DSA/PQ domain, though it does not name that sibling explicitly.

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?

There is no guidance on when to call this instead of veya_hash_blake3, veya_pq_verify, or the other PQ siblings, and no stated preconditions. The agent must infer usage entirely from the one-line phrase.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the operation is local and performs no chain write, which is real value. However, for a tool that produces secret key material it says nothing about whether the private key is returned, persisted, or how it should be handled, which is a meaningful gap.

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?

A single front-loaded sentence with the scope qualifier in parentheses. No filler; every clause earns its place.

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?

For a zero-parameter keygen tool with no output schema, the description should at minimum indicate what the agent receives back and whether the keypair is stored or returned. 'Local, no chain write' covers the side-effect profile but leaves the return value and key-handling implications unstated.

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?

The tool takes zero parameters, which is the baseline-4 case per the rubric. The description adds no parameter content because none is needed, and nothing in the schema requires elaboration.

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 (Generate) and a precise resource (ML-DSA-44 post-quantum identity keypair), and the 'local, no chain write' qualifier makes it distinguishable from sibling operations like veya_pq_sign, veya_pq_verify, and veya_register_pq_onchain. An agent can identify it without opening the schema.

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?

The parenthetical 'local, no chain write' implies this is a prerequisite step taken before signing or on-chain registration, but the description never states when to call it versus alternatives or that it precedes veya_pq_sign. Usage is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. It names the algorithm but says nothing about output format (hex signature?), the expected encoding of privateKeyHex, or whether signatures are randomized (ML-DSA is non-deterministic) — all critical for a crypto operation.

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?

A single front-loaded sentence with no waste. It is terse to the point of under-specification, but nothing is redundant.

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?

With no annotations, no output schema, and 0% parameter documentation, a one-line description is not enough for a signing tool. An agent cannot infer the key format, output format, or encoding requirements needed to call 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 coverage is 0% for both required parameters. The description's 'UTF-8 text' gives partial meaning to the message field, but privateKeyHex's expected encoding and format are left entirely unexplained in both schema and description.

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 (Sign), resource (UTF-8 text) and algorithm (ML-DSA-44), which cleanly distinguishes it from sibling veya_pq_verify and veya_pq_keygen. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as veya_pq_verify for the reverse operation. Usage is only implied by the verb.

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

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

With no annotations, the description carries the full burden, and it only discloses the algorithm and message encoding. It never says whether verification returns a boolean or throws on a malformed signature, whether a bad signature is an error or a false result, or that the operation is side-effect free.

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?

A single front-loaded sentence naming the verb, algorithm and input domain, with no filler. It is lean to the point of under-specification, but nothing is wasted.

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?

A cryptographic verification tool with no output schema and no annotations should at minimum describe the result shape and failure behavior; neither is given. An agent calling this must guess whether success is a boolean, a status object, or an error path.

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 0% across three required parameters. The phrase 'UTF-8 text' hints at how the message argument is interpreted, but nothing explains the hex encoding expected for publicKeyHex/signatureHex, the minimum lengths, or the ML-DSA-44 key/signature sizes.

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?

It states a specific verb (verify) and a precisely bounded resource (an ML-DSA-44 signature over UTF-8 text), which distinguishes it from veya_pq_sign, veya_pq_keygen and veya_pq_fingerprint in the PQ family. It does not explicitly name those alternatives, but the algorithm and input-encoding detail make the scope unambiguous.

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?

There is no when-to-use guidance, no statement of prerequisites (e.g. that the key and signature must be hex-encoded ML-DSA-44 artifacts), and no routing to sibling verification tools such as veya_verify_secure_message or veya_verify_transaction. Usage is only weakly implied by the tool's name and verb.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely useful trait: the anchor write path is gated on a product API key plus a payer key. Beyond that it is silent on permissions, whether the plain prove path is read-only, what gets written on-chain, and failure behavior.

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?

Two tightly written, front-loaded sentences with no filler; the input forms lead and the anchor caveat follows. It is terse to the edge of under-specification, which is the only thing keeping it from a 5.

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?

For a seven-parameter tool with zero required fields, no annotations, no output schema, and 0% param coverage, the description omits too much: the prove-vs-verify contract, environmentId, key requirements for non-anchor calls, and return shape are all unaddressed.

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 0%, so the description must compensate, and it names text, canonical JSON, receipt hash, anchor, and both keys — mapping to roughly six of seven parameters. It adds no format or validity semantics and never mentions environmentId, so the compensation is partial.

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 ('Prove') and three concrete input forms (text, canonical JSON, receipt hash), so the agent knows what it operates on. However, it does not distinguish itself from close siblings like veya_anchor_proof or veya_verify_proof_api, and 'Prove' alone leaves the create-vs-verify ambiguity partly unresolved.

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?

The only conditional guidance is the anchoring clause ('Anchor writes only when...'), which is behavioral rather than a when-to-use rule. There is no statement of when to pick this over veya_anchor_proof, veya_verify_proof_api, or veya_list_proofs, and no prerequisites or exclusions for the non-anchor path.

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

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

No annotations exist, so the description carries the full burden. 'Fetch' implies a read-only operation and 'public' implies no auth is required, but the description says nothing about not-found/error behavior, rate limits, or whether the id namespace is shared with other tools — significant gaps for a no-annotation tool.

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?

A single complete sentence with zero filler and the resource front-loaded after the verb. It is efficient, though so terse that it borders on under-specification rather than model conciseness.

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?

With no annotations and no output schema, the description should describe what is returned and how failures surface. It does neither, leaving an agent unable to anticipate the response shape or error conditions for this fetch tool.

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 0% and the single 'id' parameter is only typed as a non-empty string. The description's 'by id' confirms the parameter identifies the agent, which is a small but real addition over the bare schema, though no format or scope (opaque id vs. name/slug) is clarified.

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 ('Fetch') and resource ('public agent') scoped to a single record ('one ... by id'). It implicitly distinguishes itself from the sibling list tool (veya_public_list_agents) via 'one', but never names that alternative, so it falls short of a 5.

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

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

Usage is only implied: the word 'public' hints this is for unauthenticated/publicly-exposed agents, contrasting with veya_list_agents or veya_read_agent_onchain, but there is no explicit when-to-use, when-not-to-use, or prerequisite statement.

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

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

No annotations are provided, so the description carries the full burden. 'Fetch' implies a read, but it says nothing about permissions, whether the certificate is public/unauthenticated, what happens when the id does not exist, or what form the certificate is returned in. For a zero-annotation tool this is a substantial gap.

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?

A single short sentence with the resource and key front-loaded; nothing is wasted. It is terse to the point of under-specification, but no sentence is filler.

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?

With no output schema, no annotations, and no parameter documentation, the description should at least say what a certificate object contains and what the failure mode is. It supplies neither, so an agent cannot anticipate the response or error behavior.

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 0% and the id parameter is only typed as a non-empty string. The description repeats 'by id' but adds no format guidance (UUID, fingerprint, opaque cert id) or example, leaving the agent to guess what a valid identifier looks like.

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 ('Fetch'), resource ('public certificate'), and lookup key ('by id'). The singular phrasing implicitly separates it from the sibling veya_public_list_certificates, though that sibling is never named explicitly.

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?

There is no statement of when to use this versus alternatives such as veya_public_list_certificates, nor any prerequisite beyond the implied 'you must have an id'. The agent must infer the routing decision from the tool name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Fetch' implies a read, and 'public' hints at no authentication, but nothing is said about rate limits, behavior when the id is unknown, or the shape of the returned proof.

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?

One short, front-loaded sentence with no filler or repetition. It is efficiently written, though the brevity comes at the cost of the detail noted in other dimensions.

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?

For a simple one-parameter read tool this is close to adequate, but with no annotations, no output schema, and no parameter description, the agent still lacks the id format and failure behavior. The minimum viable information is present but incomplete.

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 coverage is 0% and the single parameter is documented only as a string with minLength 1. The description's 'by id' merely restates the parameter name and adds no format detail (UUID, hash, opaque token), so it does not compensate for the coverage gap.

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?

The description gives a specific verb ('Fetch') and resource ('public execution proof') plus the lookup key ('by id'), which is enough to distinguish it from list-style siblings such as veya_list_executions and veya_list_proofs. It falls short of 5 because it never names those alternatives or clarifies the slight ambiguity between 'execution' and 'proof'.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of prerequisites or alternatives. The only implied usage signal is 'by id', which tells the agent it needs an identifier but not where to get one or which sibling to call first.

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

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

No annotations are provided, so the description carries the full burden and delivers almost nothing: it does not state that this is a read-only operation, whether pagination is required, what the default limit is, or whether results are ordered or capped. For a list tool with zero annotation coverage this is a meaningful gap.

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?

A single short sentence with no wasted words, so structure is clean. But the terseness here reflects under-specification rather than economy, leaving the definition thin for the task.

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?

With no annotations, no output schema, and undocumented parameters, the description is the sole source of behavioral context and provides almost none. It is not sufficient for an agent to call this tool confidently relative to its siblings.

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 0%, so neither the schema nor the description explains the limit/offset parameters, their defaults (limit has a 1-100 range, offset a minimum of 0), or pagination semantics. The description does not compensate for the coverage gap at all.

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 verb and resource ('List ... agent registry rows'), which is better than a bare name restatement. However, 'public' is the only differentiator from the sibling veya_list_agents, and 'registry rows' is vague about what is actually returned. An agent can guess the gist but not the scope distinction.

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?

No when-to-use guidance, no mention of the closely related siblings veya_list_agents or veya_public_get_agent. The agent is left to infer that this is the paginated public listing versus the single-record getter.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a read, but it says nothing about pagination behavior, default limit, ordering, or whether results are public/unauthenticated despite the 'public' prefix.

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?

A single front-loaded phrase with no wasted words, but it is terse to the point of under-specification rather than genuinely efficient prose.

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?

A paginated list tool with two undocumented parameters, no output schema, and no annotations leaves the agent without enough to call it correctly (e.g., default/max limit of 100, offset semantics, result ordering).

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 0%, so limit and offset have no documented meaning anywhere. The description does not mention pagination at all, failing to compensate for the complete coverage gap.

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 (List) and resource (public certificate / attestation rows), and the singular sibling veya_public_get_certificate plus veya_anchor_pq_attestation make the plural-list scope distinguishable. It does not explicitly name alternatives, but the verb distinguishes it well enough.

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?

There is no statement of when to use this tool versus veya_public_get_certificate or veya_public_list_agents, no prerequisites, and no indication of what kinds of certificates/attestations appear. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only aggregate via 'stats' and 'product API', but says nothing about authentication, rate limits, caching, or freshness. For a zero-parameter read endpoint the risk is low, yet the disclosure is still thin.

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?

A single short sentence with no filler, and the resource is front-loaded. It loses a point only because the parenthetical is doing work the main clause should do more explicitly.

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?

With no output schema, the description is the only place return content could be characterized, and it only hints at the subject matter ('verified agents / proofs') without describing the shape of the stats or timeframe. Adequate for a simple zero-param read, but incomplete on what comes back.

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?

The tool takes zero parameters, so there is no parameter semantics for the description to add. Baseline 4 applies per the zero-param rule.

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?

The description identifies the resource (public registry stats) and scopes it loosely to 'verified agents / proofs', which separates it from the list-style siblings like veya_public_list_agents. However, it is a bare noun phrase with no verb and 'stats' is vague about what is actually returned (counts, totals, timestamps). An agent knows the topic but not precisely what the call yields.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative despite dozens of siblings covering overlapping ground (veya_public_list_agents, veya_public_list_certificates, veya_list_proofs). The agent must infer that this is the aggregate/summary counterpart to those list tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that this is a read from an on-chain contract (Veya.sol) and the identifier format, but does not state authentication requirements, rate limits, whether the read is public, error behavior if the agent is not found, or what the returned record contains.

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?

A single, front-loaded sentence with no wasted words. It efficiently communicates the core action and the key identifier constraint.

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?

For a simple one-parameter read tool with no output schema and no annotations, the description is minimally adequate: it tells the agent what it does and what identifier to supply. It still lacks details about return content and failure modes, which would help an agent use 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 0%, so the description must compensate. It specifies that the required parameter is a '16-byte UUID hex', which adds meaningful format context beyond the schema's minLength=32. However, it does not clarify casing, prefix handling, or other formatting details.

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 ('Read'), resource ('agent record'), location ('from Veya.sol'), and identifier type ('by 16-byte UUID hex'). This clearly identifies what the tool does, though it does not explicitly differentiate itself from sibling tools like veya_public_get_agent or veya_read_environment_onchain.

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?

The description gives no guidance on when to use this tool versus alternatives such as veya_public_get_agent or other on-chain read tools. It only names the operation, leaving the agent to infer context from the tool name and siblings.

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

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

With no annotations, the description carries the full burden; it does disclose that this is a read against the Veya.sol contract and implies a non-mutating lookup, which is useful. It says nothing about return shape, whether the record can be absent, or latency/cost of an onchain read.

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?

A single front-loaded sentence that names verb, resource, source, and key format with zero filler. Nothing to trim.

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?

There is no output schema and no annotations, so the description is the only place an agent could learn what a 'environment record' returns or how a missing record is signaled; neither is covered. For a simple one-param read this is workable but incomplete.

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 coverage is 0% and the schema only enforces minLength: 32, so the description's '16-byte UUID hex' is genuinely additive — it tells the agent the expected encoding (32 hex chars encoding 16 bytes). No other parameter detail is needed for a single-param tool.

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 (read), resource (environment record), source contract (Veya.sol), and key format (16-byte UUID hex). It implies an onchain read that differs from the sibling veya_get_environment, but never names that sibling or the distinction explicitly.

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?

No when-to-use or when-not-to-use guidance. The word 'onchain' hints at a source distinction versus veya_get_environment / veya_list_environments, but the agent must infer when this tool is the right choice and there are no stated prerequisites.

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

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

No annotations provided, so the description carries the full behavioral burden. It adds that the row must be owned by the API key (an authorization/scoping constraint), but says nothing about return format, error behavior, or permission requirements.

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?

A single front-loaded sentence with zero waste. Every word contributes to scope and purpose.

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?

For a 3-parameter read tool with no annotations and no output schema, the description is too terse. It omits parameter semantics and behavioral details an agent would need 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 0% across three parameters. The description hints that 'id' identifies the memory row and 'apiKey' is the owner key, but leaves 'environmentId' entirely unexplained and provides no format or type semantics for 'id'. It does not compensate for the lack of schema documentation.

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 ('Read'), resource ('memory row'), cardinality ('one'), and ownership scope ('owned by this API key'). This implicitly distinguishes it from siblings like veya_list_api_memory (list), veya_store_memory (write), and veya_invalidate_memory (delete), though none are named.

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?

No when-to-use guidance, no alternatives, no prerequisites beyond the ownership constraint. An agent must infer that this is the tool for fetching a single memory row by ID rather than listing or writing.

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

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

With no annotations, the description carries the full disclosure burden. It does surface one useful trait (a two-phase flow: on-chain tx from YOUR wallet, then product-API confirmation), but says nothing about gas cost, required permissions, whether registration is irreversible, or what happens on failure. For an on-chain write this leaves major behavioral gaps.

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?

Two short sentences with no padding, and the core action is front-loaded. The second sentence is slightly muddy but still concise, so it earns its place.

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?

This is a complex on-chain write with 6 parameters, no annotations, and no output schema, yet the description is only two sentences and omits required-parameter expectations (0 marked required is suspicious for a write), the API-key requirement for writes, and the post-registration outcome. Far more context is needed given the tool's complexity.

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 only 33% (apiKey and payerPrivateKey are documented; envType, environmentId, pqPubkeyHashHex, environmentUuidHex are not). The description only adds a note about passing environmentId, leaving three parameters undocumented in both schema and description, so it does not compensate for the coverage gap.

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?

The description names a specific verb (registerEnvironment) and resource (Veya.sol environment), so the agent can roughly tell it is an on-chain registration tool. However, the second sentence blurs the purpose by describing a separate product-API confirmation step, and no sibling (e.g. create_environment, register_pq_onchain) is referenced to disambiguate. Purpose is inferable but not sharply bounded.

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?

The only guidance is 'Pass product environmentId to confirm the tx on the product API', which hints at one input but gives no when-to-use/when-not conditions, prerequisites, or alternatives to the many sibling registration/environment tools. An agent gets no rule for choosing this tool over create_environment or register_pq_onchain.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints that this is a gas-paying on-chain write ('from YOUR wallet'), but does not disclose irreversibility, gas cost, API-key auth requirements, failure modes, or what state is created. For a write tool with zero annotation coverage this is a significant gap.

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?

A single front-loaded sentence that packs the identity generation, the on-chain target, and the wallet source without padding. Efficient, though it compresses several distinct steps into one clause at the cost of clarity about sequencing.

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?

A multi-step on-chain mutation with no annotations, no output schema, an undocumented envType parameter, and zero required parameters. The description should at minimum explain envType, gas/auth implications, and whether the identity is persisted on-chain, none of which it covers.

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 coverage is only 67%: apiKey and payerPrivateKey are described in the schema, but envType has no description anywhere. The description's 'environment' and 'from YOUR wallet' loosely gesture at envType and payerPrivateKey but add no format, valid-range, or default semantics beyond the schema, leaving envType fully undocumented.

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 compound action: generate an ML-DSA identity, then register environment + commitment on Veya.sol. The 'on Veya.sol' and 'from YOUR wallet' qualifiers distinguish it from pure-offchain siblings like veya_pq_keygen and veya_register_environment, though those siblings are not named explicitly.

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?

No explicit when-to-use or when-not guidance. The agent is left to infer that this is the on-chain path versus the offchain veya_pq_keygen / veya_register_environment / veya_store_commitment siblings, and no prerequisites or sequencing (e.g. does an environment need to exist first?) are stated.

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

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

No annotations are provided, so the description carries the full burden. 'Deny stays deny' hints at sticky/cached denial behavior, which is genuinely useful, but it says nothing about authentication needs (apiKey), what happens on allow, whether routing has side effects, or what the response contains. For a 7-parameter tool with zero annotation coverage this is a large gap.

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?

The two sentences are front-loaded and waste no words, but the brevity is under-specification rather than effective conciseness for a complex routing tool. Sizing is inappropriate to the tool's surface area.

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?

With 7 parameters, 5 required, no parameter descriptions, no annotations, and no output schema, the description is nowhere near complete enough for an agent to invoke this correctly. Critical details like what 'tool rule' is checked, what the return signals, and how apiKey is used are all absent.

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 0% across 7 parameters, including 5 required ones (environmentId, id, fromAgent, toAgent, tool) plus apiKey and an untyped payload. The description explains none of them and adds no meaning beyond the schema, so it 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.

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

The name promises routing (veya_route_message) but the description actually describes a policy lookup: 'Check the saved tool rule for this API key before routing.' An agent cannot tell whether this tool routes a message or merely gates it, and the purpose is effectively a restatement of an internal implementation step rather than a clear verb+resource. It never distinguishes itself from siblings like veya_route_secure_message or veya_set_tool_policy.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. 'Before routing' vaguely implies it belongs in a routing flow, but the agent is not told when to call this versus veya_route_secure_message or how it relates to veya_set_tool_policy.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: an API-key policy check gates the operation, and the payload is sealed with Kyber-768 plus signed with ML-DSA-44. It does not explain failure behavior when the rule denies, idempotency, or the key material requirements, leaving meaningful gaps for a mutation/route tool.

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?

A single front-loaded sentence sequences the policy check before the action, with no filler. It is efficient, though it compresses two distinct steps into one clause.

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?

For a 9-parameter crypto routing tool with no annotations, no output schema, and 0% schema coverage, one sentence is insufficient. The description omits parameter meaning, error/denial behavior, and any indication of what the caller receives back.

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 0% across 9 parameters, so the description must compensate and largely does not. It only obliquely references 'this API key' (apiKey) and 'message' (payload), leaving environmentId, id, fromAgent, toAgent, tool, senderPrivateKeyHex, and senderPublicKeyHex entirely unexplained.

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?

The description names a specific flow: check the saved tool rule for the API key, then wrap a message in a Kyber-768 session and ML-DSA-44 signature. This clearly identifies the verb (route/secure) and resource (message), and the crypto primitives distinguish it functionally from plain veya_route_message. It stops short, however, of naming that sibling or any other alternative, so the differentiation is inferred rather than stated.

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?

There is no explicit when-to-use or when-not-to-use guidance. The phrase 'an allowed message' implies a policy gate, but the description never says which alternative (veya_route_message, veya_seal_decision) to pick or under what conditions. An agent must guess at the routing context.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: the required auth ('product API key') and the failure mode ('consensus_reached: false if validators are unreachable'). It still omits side effects (does this mutate server state?), idempotency, and the shape of a successful return, which matter for a tool named 'run'.

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?

Three short sentences with zero filler, and the core purpose is front-loaded ahead of the prerequisite and return caveat. Tight and readable, though the return sentence could be folded into a single clearer clause.

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?

No output schema, no annotations, and 0% parameter coverage mean the description must do everything, but it leaves taskId semantics, payload contents, and the distinction from veya_client_run_consensus unexplained. The consensus_reached note is a good start but far from sufficient for a tool with a nested payload and required identifiers.

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 0%, and the description only implies apiKey via 'product API key'. It says nothing about taskId (the sole required parameter) or the payload object, so it fails to compensate for the documentation gap in a 3-parameter, nested-schema tool.

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 ('Run') and a well-defined resource ('2-of-3 BLAKE3 consensus on this server's validator list'), so an agent knows exactly what the operation does. However, it never distinguishes itself from the close sibling veya_client_run_consensus, leaving the agent to guess which consensus variant to call.

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?

The description gives a prerequisite ('Needs a product API key') but no guidance on when to prefer this tool over veya_client_run_consensus or the broader veya_* family. No exclusions, no context conditions, no mention of what taskId represents.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: not whether this is a write/mutation, what state or artifacts it creates, whether it is idempotent or reversible, or any rate/auth limits beyond the key requirement already stated in the schema's apiKey description.

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?

Two short sentences that are front-loaded, so it is not bloated, but the second sentence restates a schema constraint and the cryptic '(Build)' tag spends words without adding meaning.

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?

An 8-parameter write-style tool with 25% schema coverage, a nested payload object, and no annotations or output schema needs substantially more description to be safely invoked. The definition leaves the agent guessing about required semantics and side effects.

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 coverage is only 25% across 8 parameters, so the description must compensate, but it explains nothing about environmentId, agentId, eventType, payload, seal, disclose, or sessionToken. The sole hint (API key needed) duplicates the apiKey field description in the schema.

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 verb+resource ('Run protected execution') but 'protected execution' is undefined jargon and the parenthetical '(Build)' is opaque. It does not distinguish this from siblings like veya_sealed_execute or veya_run_consensus, which an agent could easily confuse it with.

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?

The only guidance is a prerequisite ('Product API key required'), not a when-to-use rule. There is no indication of when this should be chosen over veya_sealed_execute, veya_prove, or veya_run_consensus, despite heavy sibling overlap in the execution family.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses a conditional side effect (attestExecution), a network-specific prerequisite (Mainnet environment), and a concrete failure mode with no side effect (SEAL_ENVIRONMENT_REQUIRED, nothing sent). Remaining gaps: auth expectations for apiKey and whether sealing is idempotent/reversible.

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?

Three dense sentences, purpose front-loaded, each carrying distinct operational information with little filler. Slightly telegraphic phrasing costs a little readability but not much space.

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?

No output schema and no annotations, yet the description covers the main control-flow branches and one error code. It still leaves the successful return value, apiKey usage, and the meaning of 'decision' values unspecified, which matters for a 5-parameter tool.

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 coverage is 0%, so the description must compensate for all five parameters. It gives meaning to evidenceId, decision, environmentId, and implicitly payerPrivateKey ('payer key'), but apiKey is never explained, and no formats or value constraints are added for any parameter.

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: 'Seal an evidence id and a decision', naming both required inputs. It is distinguishable from siblings such as veya_sealed_execute, though the description never contrasts itself with them explicitly.

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 conditional behavior (attestExecution fires only with a payer key or when the relayer switch is on; environmentId or VEYA_SEAL_DECISION_ENVIRONMENT_ID is needed on Mainnet), which implies when this will succeed versus fail. It does not say when an agent should choose this tool over e.g. veya_sealed_execute or veya_attest_execution.

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

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

With no annotations, the description carries the full burden. It does add real behavioral context: encryption scheme, an auth requirement (product API key), and a fail-closed failure mode when capacity is unreachable. It stops short of stating what the call returns, whether it mutates state, idempotency, or rate limits, so it is helpful but incomplete for a 6-param execution tool.

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?

Three short sentences with the core action and mechanism front-loaded, and no wasted words. It is tightly sized, though the terseness contributes to the documentation gaps noted elsewhere.

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?

For a tool with 6 parameters, 0% schema coverage, a nested payload object, and no output schema or annotations, the description is far too thin. An agent cannot determine what sessionEntropyHex or eventType must contain, or what a successful result looks like.

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 0% across 6 parameters (5 required), so the description must compensate. The phrase 'Needs a product API key' loosely maps to apiKey, but agentId, environmentId, eventType, payload, and especially sessionEntropyHex receive no explanation of meaning, format, or constraints.

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 and resource ('protected execution') plus the mechanism ('AES-256-GCM') and the location ('this server's sealed node'), which distinguishes it from generic siblings. However, it never explicitly contrasts with close siblings like veya_run_protected_execution or veya_seal_decision, leaving the agent to infer the boundary.

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?

There is no when-to-use / when-not-to-use guidance and no routing to any of the many execution-related siblings. The only selection hint is an implicit prerequisite ('Needs a product API key'), which is a precondition rather than usage guidance.

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

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

With no annotations, the description carries the full burden. It does disclose the authorization requirement (owning API key) and persistence semantics ('saved on that account'), which is meaningful context for a write. However it omits whether the call overwrites an existing policy, whether it is idempotent, and what a failure looks like.

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?

Three tight sentences, front-loaded with the action, then the prerequisite, then the persistence effect. Nothing is wasted and no sentence is filler.

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?

For a 5-parameter mutation with no annotations and no output schema, the description covers the essential semantics but leaves the agent guessing about return values, overwrite behavior, and error conditions. Adequate but with visible gaps.

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 0% across 5 parameters, so the description must compensate, and it does conceptually map every parameter: tool ('a tool'), allowed ('allow or deny'), agentId ('for an agent'), environmentId ('the environment'), and apiKey ('the API key'). It still doesn't clarify the accepted tool identifier format or where the agentId/environmentId come from.

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: allow or deny a tool for an agent. An agent can immediately tell this mutates an access policy rather than executing, routing, or reading anything, and no sibling tool covers the same ground.

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 one real prerequisite (the API key must own the environment), which is genuine usage guidance, but says nothing about when to reach for this vs. other configuration tools or what state must exist first (environment/agent registration).

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

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

With no annotations, the description carries the full load. It usefully discloses that this is an on-chain write, that it is executed from the caller's own wallet, and that apiKey plus payerPrivateKey are both needed (implying the caller pays gas). It omits reversibility, idempotency (what happens if the commitment already exists), and any failure/rate-limit behavior.

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?

A single compact sentence with the action and target front-loaded and the credential requirement attached as a parenthetical. Nothing is padded, though the parenthetical credential note could be tighter or split for scanability.

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?

For a mutation tool with no annotations and no output schema, the description covers the critical auth prerequisite but leaves the agent without success/failure semantics, return information (e.g., tx hash), or behavior when the commitment already exists. Adequate but with clear gaps.

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 coverage is 50%: apiKey and payerPrivateKey are documented in the schema, but commitmentHex and environmentUuidHex have no descriptions. The description partially compensates by decoding commitmentHex as a 32-byte value (matching minLength 64 hex chars) and by tying the two credentials to the wallet write, but it says nothing about the required environmentUuidHex.

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?

Specific verb + resource: 'Write a 32-byte commitment to Veya.sol' names both the operation and the on-chain target, and the 'from YOUR wallet' framing separates it from read-side siblings such as veya_verify_commitment_onchain and veya_commitment_exists. It does not explicitly name those siblings as alternatives, so it stops short of a 5.

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

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

No when-to-use statement or comparison to the read-side commitment tools is offered; the agent must infer that this is the write path while veya_commitment_exists / veya_verify_commitment_onchain are the read paths. The only guidance is the parenthetical naming two credentials, which is prerequisite information rather than usage context.

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

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

With no annotations, the description carries the full burden. 'No key, no write' usefully discloses the authentication gate (and clarifies that apiKey is effectively required even though the schema lists it as optional), but it says nothing about write durability, overwrite behavior, or what memory content is written.

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?

Two terse sentences, front-loaded with the action and the auth constraint. Nothing is wasted or padded.

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?

For a mutation tool with no annotations, no output schema, and 0% parameter coverage, the description is far too thin. It omits what memory content means, the data/agent/environment relationship, and any return behavior.

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 0% across 4 parameters, so the description must compensate and largely does not. It only glosses apiKey ('behind this API key') and gestures at agent/agentId; environmentId and data remain completely undefined.

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 (store) and resource (agent memory) scoped to the API key's account, which clearly distinguishes it from veya_read_memory and veya_invalidate_memory. It does not name those siblings explicitly, so it falls just short of a 5.

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

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

Usage is only implied: an agent infers it should call this to persist memory. There is no explicit when-to-use vs read_memory/invalidate_memory guidance, though 'No key, no write' does hint at the prerequisite to invoke it.

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

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

With no annotations, the description carries the full behavioral burden, and it partially delivers by revealing the mechanism: it reads a transaction's logs and issues one eth_call per CommitmentStored event, implying RPC dependency and potentially multiple chained calls. It omits what happens when the tx contains no such events, whether the tx must be mined, and any failure semantics.

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?

One front-loaded sentence with no filler, but it is dense jargon (eth_call, commitments(digest), CommitmentStored) that trades clarity for brevity.

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?

No output schema, no annotations, and zero parameter documentation, so the description should explain what is returned (a boolean? per-event commitment digests?) and it does not. For a verification tool whose result shape determines the agent's next step, this is a meaningful gap.

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 coverage is 0% and the single parameter has no description. The phrase 'from a tx' loosely ties to txHash, but the description never states that txHash must be a 0x-prefixed 32-byte transaction hash (the schema only enforces minLength 66), nor that it is required.

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?

The description names a concrete mechanism (parse Veya.sol events from a tx, then eth_call commitments(digest) per CommitmentStored), which is more specific than the name alone. However, it describes the implementation steps rather than the outcome (what 'verify' actually yields), and never distinguishes it from close siblings like veya_commitment_exists or veya_verify_transaction.

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?

There is no when-to-use guidance at all: nothing says whether to call this before or after veya_store_commitment, or when veya_commitment_exists is the cheaper alternative. The agent must infer the workflow entirely from sibling names.

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

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

With no annotations, the description carries full burden, and it does disclose one concrete behavioral trait: the NOT_VEYA_TX error result for non-proof transactions. However, it omits read-only/safety profile, auth requirements, and what a successful response contains.

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?

Two tight sentences, front-loaded with the core action before the caveat. No filler, though 'through the product API' is slightly vague.

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?

No output schema and no annotations, so the description must explain return semantics; it only covers the failure case (NOT_VEYA_TX) and says nothing about the success shape or how to interpret a positive verification. For a verification tool this leaves the agent under-informed.

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 0% for the single required 'signature' parameter. The description implies the input is a transaction signature but gives no format, source, or length guidance, so it does not compensate for the schema gap.

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: 'Check a commitment or anchor transaction'. The phrase 'through the product API' distinguishes it from on-chain siblings like veya_verify_commitment_onchain, but it never disambiguates against the very similarly named veya_verify_transaction, leaving sibling separation incomplete.

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?

The note that 'A registration transaction is not a proof and returns NOT_VEYA_TX' gives a useful when-not signal, but no alternative tool is named for the cases this rejects (e.g., where to verify a registration transaction instead). Usage is implied rather than explicitly routed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose the verification outcome shape (boolean vs. exception), failure behavior, whether the envelope must first be produced by veya_route_secure_message, or any auth/rate constraints.

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?

A single front-loaded sentence with zero waste, which is good structure, but for a tool with a nested opaque object parameter it is terse to the point of under-specification.

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?

There is no output schema and no annotations, and the key input (message) is an unconstrained nested object whose required envelope fields are undocumented. An agent cannot reliably construct a valid call from this definition alone.

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 0% and the schema is bare: senderPublicKeyHex is an undescribed string with minLength 8, and message is a nested object with no defined properties (additionalProperties: {}). The description clarifies neither the envelope structure nor the key format, so it does not compensate for the coverage gap.

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 (Verify) and a specific resource (ML-DSA signature on a secure routed message envelope), so an agent knows the operation is verification of a routed-message envelope. It does not explicitly distinguish itself from near neighbors such as veya_pq_verify or veya_verify_transaction, which is the only thing keeping it out of a 5.

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

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

The description gives no when-to-use guidance and names no alternative, despite several overlapping siblings (veya_pq_verify, veya_verify_transaction, veya_route_secure_message). An agent must infer the routing conditions entirely on its own.

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing behavioral: no statement that the call is read-only, whether it hits an RPC/network endpoint, whether it fails or returns false for an unknown hash, or any rate/latency expectations. 'Verify' implies a safe read but that is inference, not disclosure.

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?

A single front-loaded sentence with no filler; the subject (what is verified) and the input (which chain's tx hash) arrive immediately. It is terse to the point of under-specification, but nothing in it is wasted.

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?

For a verification tool with no annotations and no output schema, the description should at least indicate what a successful verification yields (boolean, commitment record, attestation details) and what failure looks like. None of that is present, so an agent cannot predict the outcome of the call.

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?

With one parameter and 0% schema description coverage, the description does add real meaning by naming the chain (Robinhood Chain) and the input type (tx hash), which the schema's bare type string and minLength:66 do not convey. It still omits any format example, so it only partially compensates for the coverage gap.

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 (Verify) and resource (a Veya.sol commitment) and pins the input source (Robinhood Chain tx hash). This distinguishes it from sibling verify tools such as veya_verify_secure_message and veya_verify_proof_api, though it never explicitly contrasts itself with veya_verify_commitment_onchain, which sounds very close.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of prerequisites such as needing the commitment to have been anchored on Robinhood Chain first. With four or more sibling 'verify' tools available, the absence of routing advice leaves the agent guessing.

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

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

With no annotations, the description carries the full burden, and it does disclose a genuine behavioral trait: writes are signed and sent by the caller's own wallet, not the host relayer. That is useful architectural context, but it says nothing about what the call returns, whether it is read-only, 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.

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

A single, well-formed sentence with the operative fact front-loaded and no filler. It is appropriately sized for an informational tool, though the terse construction is the entire description.

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?

For a zero-param informational tool with no annotations and no output schema, the description conveys the core content but does not describe the shape of the response or how an agent should act on it. It is minimally adequate rather than complete.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the schema. Baseline 4 applies; no parameter-level information is needed.

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?

The description states a specific subject (how on-chain writes work) and asserts the key fact that the caller's own wallet sends writes rather than the host relayer. However, it reads as a documentation/reference tool despite the 'status' name, and it does not distinguish itself from the many write-related siblings (veya_anchor_proof, veya_register_pq_onchain, veya_store_commitment). The purpose is understandable but not sharply differentiated.

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?

There is no indication of when an agent should call this tool, what question it answers that other tools don't, or any conditions/exclusions. No alternatives are named despite a crowded sibling set covering on-chain writes.

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