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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds material context they do not carry: experimental status, the ADMIN-key-only auth constraint, exclusion of inference keys, and the refusal of x402 wallet auth. It also bounds the result to the last 50 events, which is behaviorally important.

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 what it returns, then the caveats. Nothing is redundant and no sentence could be dropped without losing an auth or scope 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 parameterless read endpoint with no output schema, the description covers the essentials: what is returned, how many records, and every auth prerequisite. An agent has everything needed to decide whether it can call it.

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 to explain; baseline is 4. The description's fixed 'last 50' scope correctly signals that no filtering or paging arguments exist.

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 precise verb+resource+scope: 'Get the last 50 exceeded rate-limit events for the account.' This is distinguishable from the sibling venice_api_key_rate_limits, which concerns current limits rather than a historical log of exceeded events.

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 clear operational context — experimental endpoint, ADMIN API key required, inference keys cannot call it, and no x402 wallet auth — which tells the agent whether it is even eligible to call it. It does not, however, explicitly name an alternative tool or a when-not-to-use condition relative to the rate-limits sibling.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds a genuinely useful behavioral constraint — that x402 wallet auth is rejected and an API key is mandatory — but says nothing about rate-limit semantics, caching, or response freshness.

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 sentences with no filler, front-loading the returned data before the auth constraint. 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?

With no output schema and no parameters, the description carries the burden of describing the return payload, and it does so by listing the five fields returned. The auth requirement is also covered. It stops short of routing the agent away from the similar key/billing siblings, which is the only 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The schema is trivially empty and adds no competing information.

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 ('Get') and enumerates the exact resources returned: balances, access status, tier, expiration, and model-specific rate limits. It is distinguishable from most siblings, though it never explicitly contrasts itself with the closely named venice_get_api_key, venice_api_key_rate_limit_logs, or venice_billing_balance, which also touch key/billing data.

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 one actionable precondition ('API key required — this endpoint does not accept x402 wallet auth'), which tells the agent when this call will succeed. However, it names no alternative tool and gives no condition for choosing this over venice_get_api_key or venice_api_key_rate_limit_logs, so 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?

Goes well beyond the annotations: it discloses the 1 MiB upstream JSON cap, the exactly-once transcription/charging guarantee, per-MCP-session in-memory handles, the 10-minute TTL, the 16-result LRU eviction, that an expired handle errors rather than silently re-transcribing, and that both x402 wallet auth and API keys are accepted. This also explains why the annotations mark it non-read-only and non-idempotent.

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

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

Front-loaded with the purpose, then ordered by importance (input handling, size limit, paging, handle lifetime, auth). The paging and handle-lifetime sentences are long and could be split, but for a tool with genuinely intricate stateful behavior almost every clause carries information an agent needs.

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 exists, and the description compensates by explaining the paged result shape (result_handle plus next_timestamp_offset/next_text_offset on later pages). Model, language, and response_format semantics are left undocumented, which is the main remaining gap for a 9-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?

With 67% schema coverage and 9 parameters, the description reinforces the relationship between audio_url, result_handle, text_offset/timestamp_offset and the paging fields, and adds the 8000-character page size that the schema only alludes to. model, language, and response_format receive no explanation in either place, so it is good but not exhaustive.

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 opening sentence gives a specific verb+resource ("Transcribe audio") and immediately scopes the input mechanism (server-side URL fetch forwarded as multipart/form-data). No sibling tool performs ASR – venice_tts, venice_voice_clone and venice_audio_quote are clearly distinct – so the purpose is unambiguous 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 description gives concrete usage conditions for the two invocation modes (audio_url for a fresh transcription, result_handle for subsequent pages) and states what happens when a handle is no longer valid. It does not name or exclude alternative tools, but no sibling overlaps this capability, so the context is clear.

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 already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered structurally. The description adds a genuinely useful behavioral fact not in the annotations — "No authentication required" — plus the pre-queue timing guarantee, though it says nothing about rate limits or quote validity windows.

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, front-loaded with the core action and scope; each sentence contributes (purpose, use case, auth precondition) with no redundancy.

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 3-param read-only quote tool with full schema coverage and annotations, this is nearly sufficient. The one minor gap is that no output schema exists and the description never indicates what the quote actually returns (e.g., cost amount, currency), leaving the agent to discover the response shape empirically.

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

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

Schema description coverage is 100%, so model, character_count, and duration_seconds are all documented in the schema with their constraints. The description adds no parameter guidance beyond noting nothing about model-specific price dimensions, so 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 specific verb (get a price quote), resource (music generation), and timing constraint (BEFORE queuing), which cleanly distinguishes it from the sibling venice_music_generate. An agent can tell immediately this is a pre-flight costing call, not a generation 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?

"BEFORE queuing" and "Useful for budgeting" give clear context for when to reach for this tool rather than the generator. No explicit when-not conditions or named alternatives (e.g., venice_video_quote for video), so it stops short of the top tier.

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 already cover read-only, idempotent, non-destructive semantics, so the description earns credit for adding auth-specific behavior: admin-key requirement and rejection of inference keys and x402 wallet auth. It omits return shape and any rate-limit or caching behavior, but adds real context beyond the annotations.

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

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

Three short sentences, purpose front-loaded, followed by the auth constraints that matter most. No filler or redundant restatement of the title.

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 does carry the return-value burden and names the three credit dimensions returned. Auth and scope are fully covered; a minor gap is that it doesn't explain units, currency conversion, or whether bundled credits refresh.

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; 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?

Specific verb ('Get') plus resource ('billing balance') and the exact quantities returned (USD, DIEM, bundled-credit availability) scoped to the authenticated account. This distinguishes it cleanly from venice_x402_balance and venice_billing_usage_* 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?

Clearly states the prerequisite (ADMIN API key) and two explicit exclusions (inference keys cannot call it; x402 wallet auth is not accepted), which effectively routes callers toward venice_x402_balance. No alternative tool is named directly, so it stops short of a full when/when-not/alternatives triad.

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 already establish this as a safe, idempotent read, but the description adds genuinely new operational facts: a 10-minute cache window, an ADMIN-key requirement that inference keys cannot satisfy, and the exclusion of x402 wallet auth. Those are real behavioral traits an agent cannot derive from the schema or annotations.

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, each carrying distinct information (purpose, caching, parameter rule, auth), with the core purpose front-loaded. Slightly bloated by the closing 'does not accept x402 wallet auth' clause, but nothing is wasted or 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 output schema, the description does a fair job sketching the response shape ('aggregated usage by date, model, and API key') and covers caching and auth constraints. It stops short of describing metrics returned (tokens, cost) or any pagination, which keeps it from being fully self-sufficient for an analytics endpoint.

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

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

Schema description coverage is 100%, so both the mutual exclusivity of lookback vs. start_date/end_date and the YYYY-MM-DD format are already documented in the schema. The description only restates the either/or rule, adding no format, default, or boundary detail beyond it. 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?

It names a specific verb (get) and resource (aggregated usage) and scopes it to date/model/API key dimensions, so the agent knows exactly what comes back. However, it never differentiates from the closely named sibling venice_billing_usage_history, leaving the agent to guess which billing usage tool to pick.

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?

It gives a clear selection rule for parameters ('Choose either lookback or a complete start/end date range') and states the access condition (ADMIN key). But it offers no guidance on when to prefer this tool over venice_billing_usage_history or venice_billing_balance, which is the main routing decision an agent faces here.

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?

Goes well beyond the annotations (which only cover read-only/idempotent safety) by disclosing the 64 KiB page-failure mode with no partial rows or next cursor, the cursor-format coupling, ascending ordering, and the ADMIN-key vs inference-key and x402 auth restrictions. These are exactly the behavioral traits an agent cannot infer from structured fields.

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

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

Front-loaded with the core purpose and pagination model, then layered constraints, with no filler sentences. It is dense and mostly non-redundant, though a couple of points (default 10 rows, cursor/format coupling) restate what the schema already says.

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 paginated billing tool with no output schema, it covers pagination mechanics, failure behavior, auth requirements, and continuation semantics thoroughly. An agent has everything needed to call it correctly across first-page and continuation scenarios.

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 already 83%, so the schema carries most parameter meaning. The description still adds value by explaining that cursor continuation drops filters and that CSV cursors persist format=csv, which clarifies how cursor interacts with the other parameters beyond the schema text.

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 (walk) and resource (billing usage) plus ordering (ascending timestamp) and mechanism (cursor pagination), which is precise enough to act on. It does not, however, explicitly distinguish itself from the sibling venice_billing_usage_analytics, so the differentiation is implied rather than 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?

Gives strong operational guidance: cursor continuation must omit original filters, CSV cursors encode format=csv, and the endpoint is explicitly not the deprecated /billing/usage. It also states the ADMIN key requirement and that x402 wallet auth is unsupported, which routes the caller correctly, though it never names the analytics sibling as the alternative for aggregated data.

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 already cover the safety profile (readOnly/idempotent/non-destructive/closed-world), so the bar is lower, and the description earns credit by adding real auth context: 'API key required — this endpoint does not accept x402 wallet auth,' which meaningfully distinguishes it from the venice_x402_* siblings. It also signals pagination behavior, though it doesn't describe return 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?

Two tightly written sentences with zero filler, and the core purpose is front-loaded ahead of the auth caveat. 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?

With no output schema, the description carries some burden it doesn't fully meet: return format of the reviews and the semantics of page/pageSize are left unexplained. It is adequate for identifying and selecting the tool, given annotations cover safety, but not complete for confident 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 only 33% — only 'slug' is documented, while 'page' and 'pageSize' carry no descriptions at all. The description merely says 'paginated' without explaining page numbering, page size limits, or defaults, 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 precise verb+resource pair ('List paginated public reviews for a Venice character'), which is unambiguous and distinct from the character-reading siblings like venice_get_character. It stops short of naming a related tool to contrast against, but the resource itself is specific enough to disambiguate.

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 implies usage (fetch reviews for a given character) and notes the auth prerequisite, but never states when to prefer this over alternatives such as venice_get_character for character metadata, nor any exclusions. Usage is inferable rather than guided.

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?

The description adds valuable behavioral context beyond the annotations: it discloses that calls are non-streaming plaintext, that enable_e2ee is rejected (a critical constraint for an agent that might try to use it), and that the server does not encrypt chat. It also mentions x402 wallet auth as an option. This is useful, non-obvious information. The annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false) are somewhat contradictory with the open-world nature of an LLM that can be prompted to do anything, but the description doesn't address that.

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 concise, front-loaded with the core purpose, and each sentence adds a distinct piece of information (operation, streaming behavior, encryption rejection, censorship policy, auth methods). It could be slightly more structured, but it effectively avoids waste.

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 tool's complexity (18 parameters, nested objects, no output schema) and the rich sibling set, the description is minimally adequate but leaves significant gaps. It doesn't explain how to select a model, how to handle multimodal inputs, how tool calling works, or what the response format looks like. The absence of an output schema places a higher burden on the description, which is not fully met.

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 39%, which is moderately low. The description adds meaning for one parameter (enable_e2ee) by stating it is rejected, but otherwise provides no parameter-level guidance. With 18 parameters and many undocumented in the schema (e.g., temperature, top_p, stop, tools have no descriptions), the description fails to compensate for the coverage gap. Baseline for low coverage is 3 only if the description partially compensates; here it does so minimally.

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 clearly states the core action: 'Run an OpenAI-compatible chat completion via Venice's text-model catalog.' This is a specific verb+resource. However, it doesn't explicitly distinguish itself from the closest sibling, venice_responses, which is likely another chat/completion endpoint. The agent must infer the difference.

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 provides no explicit when-to-use guidance. It doesn't clarify when to choose venice_chat over venice_responses, venice_chat_with_character, or venice_web_search. The mention of uncensored NSFW prompts is a capability, not a usage condition.

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 only give the generic safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the description carries the burden for auth behavior and content policy. It does this well, disclosing the x402-vs-API-key split for character lookup and the uncensored/NSFW-permitting nature of the endpoint. It stops short of describing streaming, billing implications, or return 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?

The purpose is front-loaded in the first clause, followed by the auth caveat and content-policy note. Three compact sentences with no filler, though the em-dash aside is slightly dense.

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 should say more about what comes back and how messages/model are used, which it does not. It does cover the two genuinely non-obvious facts (auth path and content policy), making it adequate but with clear gaps for a 5-parameter generation 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% across 5 parameters, so the description must compensate and largely does not. It only gestures at character_slug ('by slug'); messages, model, max_tokens, and temperature get no explanation of format, defaults, or constraints beyond the raw JSON types.

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 ('Chat with a Venice character by slug'), which is enough to distinguish it from the generic venice_chat sibling. It never explicitly contrasts itself with venice_chat or venice_responses, but the resource scope 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?

It supplies one concrete usage prerequisite: character lookup is API-key-only while chat supports x402, so x402 users must fetch character info another way first. However, it never explicitly says when to prefer this over venice_chat, nor does it name venice_get_character/venice_list_characters as the lookup route, leaving the agent to infer the alternative.

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?

Adds 'No authentication required' and characterizes the list as 'live, authoritative,' which goes beyond the readOnly/idempotent/non-destructive annotations by signalling dynamic, current data rather than a static enum. It does not describe the return shape or count, but with no output schema and full annotation coverage the bar is lower.

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, front-loaded with the core action and resource, then the auth constraint. No filler; every clause carries information.

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, no-auth list tool whose safety profile is fully covered by annotations, the description is essentially complete: it conveys what is returned (network slugs) and the calling constraint (no auth). Minor room to state the return format explicitly, but nothing essential is missing.

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 baseline is 4. There is nothing for the description to clarify beyond what the empty schema already implies.

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 ('network slugs'), plus the scoping detail that these are the slugs accepted by venice_crypto_rpc. This cleanly distinguishes it from the sibling venice_crypto_rpc, which consumes rather than produces this list.

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?

Naming venice_crypto_rpc as the consumer implicitly tells the agent this is the discovery call to make before invoking the RPC tool. There is no explicit when/when-not or rival alternative named, but the workflow relationship is clear.

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?

Goes well past the annotations (destructive/openWorld/not-idempotent) by disclosing the 64 KiB rejection threshold and that Venice bills rejected oversized responses, the two auth modes (x402 wallet, no account needed, or API key), the 100-item batch cap, and the single-request rule for transaction relays. These are exactly the failure modes an agent would otherwise hit blind.

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?

Five sentences, each carrying distinct information (routing, call forms, relay rule, size/billing limit, auth), with the core purpose front-loaded. No filler or restated schema text.

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?

Although there is no output schema, the description covers the response shape ('compact JSON') and the size ceiling, plus auth, batching, and idempotency requirements. Nothing an agent needs to invoke this proxy safely and correctly is missing.

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 every parameter, but the description adds the relational semantics the schema can't convey: the two mutually exclusive call forms, the network slug coming from venice_crypto_networks, and the retry contract for idempotency_key. That is meaningful added meaning above the baseline 3.

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 ('Proxy one JSON-RPC request or a batch of up to 100 requests to a supported blockchain network') and explicitly distinguishes itself from the sibling venice_crypto_networks. An agent can immediately tell this is the execution tool versus the network-listing tool.

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

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

Gives explicit routing: use venice_crypto_networks for the live network list; use rpc_method/rpc_params for a simple call versus request for custom IDs or batches; relays must be single (not batched) with an idempotency_key, reused on retry. Conditions and alternatives are stated, not inferred.

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 exist (readOnlyHint=false, idempotentHint=false), so the description carries a lower burden, and it usefully adds that two auth modes are supported. However, it says nothing about batching limits, cost implications, or what the response contains, so it adds only modest context.

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, front-loaded sentences with no wasted words. It is efficient, though quite terse, leaving room that could have been spent on missing semantics.

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 an embeddings endpoint with no output schema, the description omits the return shape (vector vs base64) and batch behavior, and leaves encoding_format unexplained. Auth is covered, but the output-format gap keeps it from being fully 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?

Schema coverage is 67% – input and model are documented, encoding_format is not. The description adds no meaning beyond the schema (e.g., that input accepts arrays for batch, or what encoding_format changes). This is roughly baseline-adequate without compensating for the 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 (Compute) and resource (embeddings for text input), which the agent can distinguish from chat, image, TTS, or ASR siblings. The resource name alone differentiates it; it doesn't proactively name a sibling it is not, keeping it 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 conditions, and no alternatives named. The mention of x402 vs API key is about auth, not about when this tool should be selected over another.

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 already declare readOnly, idempotent, non-destructive behavior, so the bar is lower. The description still adds valuable context beyond them: the response does not reveal the full key secret, ADMIN auth is required, and x402 auth is rejected — all non-obvious operational facts.

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 resource and return contents before the auth caveats. No wasted words; each sentence carries distinct information.

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 read-only single-key lookup, the description covers scope, returned data types, secret non-disclosure, and auth requirements. With annotations covering the safety profile and schema covering the parameter, this is nearly complete; only explicit alternative routing is 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 coverage is 100% and the single 'id' param is fully documented as 'API-key ID, not the key secret.' The description restates this same distinction rather than adding new meaning, so baseline 3 is appropriate.

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 (Get) and resource (metadata, usage, balances, rate-limit details) scoped to one API-key ID. The singular 'one API-key ID' clearly distinguishes it from the sibling venice_list_api_keys, and the enumeration of returned data types makes the purpose unambiguous.

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

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

Gives clear usage context via auth constraints: ADMIN API key required, inference keys cannot call it, and x402 wallet auth is not accepted. It does not explicitly name alternatives (e.g., 'use venice_list_api_keys to enumerate all keys'), so routing is implied by the singular scope rather than 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, non-open-world). The description adds genuinely non-obvious context: API key auth is required and this endpoint rejects x402 wallet auth, a behavioral constraint not in the annotations. It omits response shape, but no output schema exists.

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

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

Two tight sentences; the core lookup is front-loaded and the auth constraint follows with zero 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 single-param idempotent read with rich annotations and a fully documented schema, the auth caveat is the key missing piece and it is present. Minor gap: no return-value shape, though no output schema is defined and this is a simple getter.

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%; the schema fully documents the slug parameter including its regex pattern and example. The description adds no syntax or format detail, so 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?

Clear verb (Get) + resource (one public Venice character) + selector (by slug). It implies a single-item lookup versus the sibling venice_list_characters, but does not explicitly name that sibling to sharpen the 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?

States the auth precondition (API key required; x402 wallet auth not accepted), which is a useful usage constraint. However, it never says when to prefer this over venice_list_characters or venice_chat_with_character, leaving alternative 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?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation. The description adds genuinely useful context beyond that: the base64 PNG return format and the dual-auth model (no Venice account required via x402). It stops short of cost, latency, or reversibility details.

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, each front-loaded with the most important fact (action, return value, auth). No filler or repetition.

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 an 8-parameter mutation with no output schema, the description usefully covers the return format and auth, but leaves a meaningful gap around the undocumented parameters and the relationship between prompt/enhance_prompt and the input image.

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?

At 63% schema coverage, several parameters (prompt, safe_mode, output_format) lack descriptions in the schema, and the tool description adds no parameter meaning at all. It doesn't clarify defaults, model-specific validation, or how the prompt interacts with the input image despite enhance_prompt hinting at that relationship.

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 ("Edit an image with a prompt") and adds the return format (base64 PNG). It does not, however, distinguish itself from close siblings like venice_image_multi_edit, venice_image_remove_bg, or venice_image_upscale, so an agent must 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?

The description names the supported auth modes (x402 wallet vs API key) but gives no guidance on when to choose this over image_generate, image_multi_edit, or other image siblings, and no exclusions or prerequisites. 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?

Annotations only establish the write/non-idempotent/non-destructive profile, so the description carries real additional weight: it discloses the uncensored NSFW policy and the fact that authentication can be satisfied via an x402 wallet without a Venice account. It stops short of 5 because it says nothing about cost, latency, rate limits, or what the response looks like (URL vs binary).

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 core action is front-loaded in the first two words, and the follow-on sentences each add distinct information (capabilities, content policy, auth). The model roster is long but earns its place as the only enumeration of valid model values available to the agent.

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 an 18-parameter generation tool with no output schema and only 56% schema coverage, the description leaves meaningful gaps: the return shape is never stated (though the 'variants' schema hint about non-binary responses is uncovered), and most optional parameters receive no narrative framing. Auth and content-policy coverage are the bright spots.

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 56%, and the description meaningfully compensates for the most important gap by supplying concrete model identifiers (Flux 2 Pro/Max, Lustify SDXL, Anime WAI, Qwen Image, GPT Image, Nano Banana Pro) where the schema only says 'Defaults to flux-2-pro.' The remaining parameters (quality, variants, aspect_ratio, style_references, enhance_prompt) are left entirely to 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 and resource ('Generate an image') and follows with the supported model roster, so an agent knows exactly what capability this exposes. It does not explicitly contrast itself with the closely related siblings venice_image_edit or venice_image_multi_edit, 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?

The description covers prerequisites rather than selection criteria: it names the two auth paths (x402 wallet with no Venice account, or API key) and notes NSFW is permitted where the model allows. It never says when to prefer this over venice_image_edit, venice_image_upscale, or the video/music generators, leaving the agent to infer from tool names 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?

Annotations already disclose the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description adds genuinely useful context beyond them: the return format (base64 PNG) and two auth paths (x402 wallet without a Venice account, or API key). It omits any cost/latency caveat even though quality 'may change pricing' and enhance_prompt 'may add time and cost'.

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 packed sentences with zero filler; the core capability is front-loaded and the auth/output facts follow. Every clause carries information.

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 correctly states the return format (base64 PNG), and it covers the auth model that an agent must resolve before calling. It is close to complete, but leaves the undocumented model/resolution/output_format params and any cost implications to the schema and annotations.

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?

Eight parameters with only 50% schema description coverage: model, prompt, image_urls, and output_format have no schema description, and the tool description compensates for none of them. It only echoes prompt and image_urls implicitly through 'single prompt' and 'multiple images'. Below the baseline 3 because the description adds essentially no semantic detail over 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+resource (edit multiple images) plus the use cases (multi-image composition / outpainting). It implicitly separates itself from venice_image_edit via the 'multiple images' scope, but never names the sibling explicitly, so the 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 'multiple images together with a single prompt' framing implies when this is preferred over single-image tools, but there is no explicit guidance on when to pick this versus venice_image_edit, venice_image_generate, or venice_image_upscale. Usage is implied rather than 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?

Annotations cover the safety profile (destructiveHint=false, idempotentHint=false, readOnlyHint=false), so the description's job is to add context beyond that — and it does by disclosing the return format and, notably, the dual auth paths (x402 wallet with no account, or API key). Auth requirements are exactly the kind of behavioral detail annotations can't convey.

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 tight sentence that front-loads the purpose, then adds return format and auth in the fewest possible words. 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 one-parameter, no-output-schema tool, the description covers purpose, output format, and authentication, which is most of what an agent needs to call it. The only missing piece is the semantics of image_url.

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 never mentions the single parameter, so the agent gets no explanation of what image_url expects (hosted URL, data URI, resolution limits) despite it being required. With coverage this low, the description should have compensated and does not.

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+resource ('Remove image background') and names the output ('transparent PNG (base64)'), which cleanly separates it from siblings like venice_image_edit or venice_image_upscale. It stops short of explicitly naming which sibling to use instead, but the function is distinctive enough to be 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/when-not guidance and no mention of alternatives among the many image tools (generate, edit, multi_edit, upscale). The agent must infer that this is the background-removal tool purely 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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered; the description adds a genuinely useful behavioral fact not in the annotations — that no authentication is required — which matters for an agent deciding whether it can call this cheaply up front.

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, zero filler, with the purpose front-loaded before the auth note.

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, no-output-schema listing tool the description is nearly sufficient, but with no output schema it could say what the list actually contains (style names/ids usable in venice_image_generate) to close the last 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; 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 ('List') and resource ('image style presets'), and ties itself to the consuming sibling venice_image_generate, so an agent can tell it apart from the other image tools without opening a 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 reference to venice_image_generate implies this is the discovery step before generation, which is useful context, but there is no explicit when-to-use statement, no exclusions, and no named alternative for the same information.

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 only carry the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds genuinely useful behavior beyond that: it normalizes the base64 requirement by fetching the URL itself, declares the base64 PNG return format, and reveals two auth paths (x402 wallet or API key). It stops short of stating failure behavior or rate limits.

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

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

Three tight sentences, front-loaded with the core action, then the URL-fetch mechanics, then return format and auth. Every sentence carries information; only the scale range in parentheses mildly duplicates the schema.

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 correctly fills that gap by declaring a base64 PNG return, and it covers auth requirements. For a single-required-parameter image tool this is nearly complete; only error modes and payload-size limits are 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 coverage is 67%: scale and creativity are already fully documented in the schema, while image_url carries no description there. The description adds the useful detail that the tool fetches that URL and uploads it, but no syntax, size, or format guidance for the URL itself. Baseline 3 is appropriate.

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 (upscale an image) plus the scale range, which is enough to distinguish it from venice_image_edit and venice_image_generate. It does not, however, explicitly name or contrast itself against those siblings, 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 implied rather than stated: the agent can infer this is for enlarging an existing image, but the description never says when to choose it over venice_image_edit, venice_image_multi_edit, or venice_image_generate, nor what preconditions apply. No exclusions or alternatives are offered.

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 already declare readOnlyHint, idempotentHint, and non-destructive semantics, so the bar is lower. The description adds meaningful context beyond that: the admin-only requirement, the auth-path exclusion (x402), and the partial-data return (last six characters only). It does not cover rate limits or pagination, but the security-relevant additions are valuable.

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, each front-loading a distinct fact: what is returned, who can call it, and what auth path is excluded. 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 zero-parameter, read-only listing endpoint with no output schema, the description covers purpose, access control, and data-exposure scope. Return-shape details are absent, but the key operational constraints an agent needs are present.

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?

Zero parameters, so baseline is 4. The schema is empty and the description correctly notes no inputs are needed, while adding auth-context constraints that function as implicit prerequisites.

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 (API-key metadata) and immediately clarifies scope: only the last six characters, not full secrets. This distinguishes it from sibling venice_get_api_key and sets expectations precisely.

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?

Explicitly states the admin requirement and that inference keys cannot call the endpoint, plus that x402 wallet auth is not accepted. Clear conditions on when the tool is usable, though it does not explicitly contrast with siblings like venice_get_api_key or venice_api_key_rate_limits.

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 already declare readOnlyHint, idempotentHint, non-destructive and non-open-world, so the safety profile is covered. The description adds the useful auth-method constraint, but says nothing about size of result sets, pagination, or filtering behavior for a 12-parameter query 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?

Two tight sentences with the purpose front-loaded and zero filler; the auth constraint follows immediately. It is efficient, though the extreme brevity also reflects the missing filter coverage.

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 12-filter listing tool with no output schema and near-zero schema coverage, the description is far too thin: no return shape, no pagination semantics, no filter documentation. Only the auth requirement is covered.

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 8% across 12 parameters, and the description compensates for none of them — no mention of tags, categories, sorting, pagination, or the deprecated tag field. With this much undocumented surface, the description carries no parameter meaning 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?

The description gives a specific verb+resource ('List public Venice characters'), which clearly separates it from the singular sibling venice_get_character. It does not explicitly name sibling alternatives, so it stops 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?

It adds a real routing constraint — API key required, x402 wallet auth not accepted — which tells the agent how to authenticate. However, it gives no guidance on when to use this vs. venice_get_character, venice_character_reviews, or the other list endpoints, and no exclusion conditions.

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 already establish readOnly/idempotent/non-destructive, but the description adds valuable context beyond them: 'No authentication required', the upstream type=all behavior, the pagination contract, and the shape of returned entries. Only missing piece is any error or 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?

Front-loaded with the core action and dense but purposeful; the pagination instruction and return-shape sentence each earn their place. Slightly heavy on semicolon-chained clauses, 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?

With no output schema, the description carries the return contract itself — naming total, next_offset, ids, and the compact-summary fields — and explains the pagination termination condition. An agent has everything needed to call and iterate 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 100%, so baseline is 3, but the description adds real nuance: it resolves the apparent tension in the schema by explaining omission is sent upstream as type=all, and clarifies that verbose switches between compact summaries and full objects beyond the schema's terse wording.

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 ('List the live model catalog') and clarifies the scope (one page at a time, compact summaries). An agent can distinguish it from detail-oriented siblings like venice_model_details or venice_model_traits, though the description never names those alternatives 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 clear operational context: omitting type fetches all types, and gives an explicit pagination loop ('call again with offset=next_offset until next_offset is null'). It does not, however, state when to prefer this tool over sibling catalog/inspection 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?

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive). The description adds genuinely new context: the mapping is 'live', no authentication is required, and the API defaults to text when type is omitted. These are behavioral facts not present in the annotations or schema.

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, front-loaded with the core purpose, then the default and auth note. No filler; every sentence carries information.

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 single-optional-parameter read tool with full annotation coverage and no output schema, the definition is nearly complete. The only gap is routing guidance relative to the other model-listing tools, but nothing needed to call it correctly is missing.

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%, and the schema already documents the 'type' parameter with its full enum-like catalog list and default. The description restates the default-to-text behavior, adding no syntax or format detail beyond the schema, 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?

The description states a specific verb and resource: 'Return the live compatible model-name to Venice model-id mapping for a model type.' This is clearly distinct from siblings like venice_list_models or venice_model_details, though it does not explicitly name those alternatives.

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?

It notes the default behavior when 'type' is omitted, which implies usage context, but never says when to reach for this tool versus the model-related siblings (venice_list_models, venice_model_details, venice_model_traits). 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description still adds real context: it is unauthenticated and only returns pricing 'when available', which the annotations do not say.

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 return payload, followed by the parameter rationale and the auth note. No filler and nothing repeated from title or schema.

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 correctly carries the burden of describing the return payload and its conditionality ('pricing when available'), plus auth status. It stops short of noting error behavior for an unknown model_id/type pair, which is the only real 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 100%, so the baseline is 3, but the description adds rationale the schema lacks: the 'type' parameter is required to keep the upstream catalog response bounded. That explains motivation without merely restating the field set.

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 and resource ('Get one exact model's full catalog row') and enumerates the payload contents (model_spec constraints, capabilities, pricing). It is clearly distinguishable from the sibling venice_list_models, which returns many rows rather than 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?

It implies the lookup use case ('one exact model') and the schema example points back to venice_list_models({type: "video"}), but the description itself never states when to prefer this over venice_list_models or venice_model_traits. Usage is inferable rather than explicit.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond them: the mapping is "live" (not cached) and "No authentication required." It does not describe the response shape or size, so this is solid but not rich.

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

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

Three short sentences, front-loaded with the purpose, then the default, then the auth note. Every sentence carries a distinct fact and nothing is 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?

With no output schema, the description carries the burden of explaining the return value, and it does so adequately ("trait-name to model-id mapping"). But for a catalog-inspection tool with many sibling metadata tools, it lacks any routing guidance, leaving a real 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 description coverage is 100% and the single parameter is fully documented in the schema, including the "Defaults to text upstream" note that the description merely restates. Baseline 3 applies since the schema does the heavy lifting and the description adds no new parameter meaning.

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: "Return the live trait-name to model-id mapping for a model type." An agent knows what it fetches. However, it never distinguishes itself from sibling model-metadata tools like venice_model_details, venice_list_models, or venice_model_compatibility_mapping.

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 and no named alternatives. The only context given is an upstream default, which is a parameter behavior rather than a usage rule. An agent cannot tell from this text when to prefer it over venice_model_details or venice_model_compatibility_mapping.

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 already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the bar is lower. The description still adds real value beyond them: it names what is destroyed ('server-side media'), gives a success-confirmation contract ('reports removal only when Venice confirms success'), and discloses auth modes (x402 wallet or API key).

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, the destructive action and its effect front-loaded, followed by the confirmation contract and auth options. 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?

Behaviorally solid for a destructive mutation with no output schema, but with 0% schema coverage on two required params the description should have explained queue_id/model matching semantics. The tool is callable, but an agent could easily pass the wrong model and misfire a destructive operation.

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 two required parameters, so the description carries the full burden and largely fails it. It never explains what queue_id identifies or whether 'model' must match the model used at generation time, which is a real ambiguity for a destructive 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?

States a precise verb and resource: 'Mark a completed music job as downloaded and delete server-side media.' It is unambiguously distinct from venice_music_generate, venice_music_status, and the video equivalents in the sibling list.

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 precondition 'a completed music job' implicitly routes the agent to check status (venice_music_status) before calling, and the name signals it is a terminal cleanup step. No explicit when-not or named alternative is given, so it stops short of a 5.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), and the description adds substantial context beyond them: dual auth paths (x402 wallet with no account, or API key), the NSFW/uncensored policy where models permit, and the exact return payload { model, queue_id }. This is rich, non-redundant behavioral 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?

Purpose is front-loaded and the sentence structure is dense and information-bearing. The enumerated model list is long but functional for model selection, so it earns its space, though it slightly inflates the text.

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 compensates by stating the return shape and the required follow-up (poll via venice_music_status), and it covers auth, model availability, and content policy. An agent has what it needs to invoke and then track the job.

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 92%, so the schema already documents the 12 parameters thoroughly; the description's model list is the only meaningful cross-reference to the 'model' parameter. Baseline 3 is appropriate since the description does not add syntax or behavior detail 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+resource ('Queue music generation') and immediately differentiates the async queue flow from siblings by instructing the agent to poll with venice_music_status. The listed models and the returned shape make the tool's identity 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 polling workflow ('poll with venice_music_status') gives clear operational context for using the result, and the auth options tell the agent how access is obtained. It does not, however, explicitly contrast this async tool against venice_music_complete (sync) for the same resource, which would be the natural when-to-use guidance.

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

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

Annotations mark it non-readonly, idempotent, non-destructive, but description explicitly notes it's a POST endpoint with body and describes return format changes over job lifecycle. It adds auth options (x402 or API key) which are useful behavior context. However, it doesn't explain polling cadence, what 'PROCESSING' progress looks like, or what happens on failure.

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

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

Front-loaded with the core purpose, then details on return types and auth in a compact three-sentence block. No wasted words.

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

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

Given no output schema and low parameter coverage, the description covers the return shapes and auth sufficiently. It leaves out polling guidance and error handling, which are minor for a status-check tool. Overall it's near-complete for 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 coverage is low (33%), and description compensates by noting the POST body includes {model, queue_id}. It doesn't describe delete_media_on_completion, but the schema has a description for that parameter, and the description does not need to duplicate it. The added context of the request shape is valuable.

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?

Clearly states it checks status of a queued music job, with specifics about return formats (JSON progress, base64 resource, or download_url). Distinguishes from venice_music_generate implicitly by referencing queued jobs, though it doesn't name the generate 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?

Implied usage: call after a music job is queued, likely following venice_music_generate. But no explicit when-to-use vs. venice_music_complete, nor when polling should stop. The mention of venice_music_complete in the delete_media parameter hints at a workflow but is not framed as 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?

Given annotations only cover a generic safety profile, the description carries the real burden and does so well: alpha/stateless status, deliberate omission of tool calling because the endpoint is unreliable, E2EE models unsupported, NSFW allowed where the model permits, and both x402 wallet and API-key auth paths.

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 tight sentences, front-loaded with what the tool is, then limitations, then capabilities and auth. Dense but each clause carries distinct information; only the auth sentence feels slightly appended.

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 7-parameter nested-schema tool with no output schema, the description covers identity, limitations, input modalities, and auth adequately. It does not describe the response shape, though 'OpenAI-compatible Responses API' gives a strong prior.

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 29%, but the description adds only broad hints (text/image input, reasoning controls) rather than explaining model selection, temperature, or the venice_parameters contents. The nested venice_parameters subfields do carry their own schema descriptions, so the heavy lifting is partly done there.

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?

Starts with a specific verb/resource framing: a stateless, OpenAI-compatible Responses API for Venice text models, supporting text/image input and reasoning controls. That distinguishes it clearly from siblings like venice_chat and venice_embeddings, though it never states 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?

Usage context is implied (stateless Responses-style generation with reasoning controls, no tool calling) but there is no explicit 'use this when / use venice_chat instead when' guidance, which matters given the large sibling set of generation 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: no authentication is required, and crucially that fetching the evidence 'does not itself establish E2EE', which prevents a false sense of security. It stops short of disclosing caching/rate-limit behavior or exactly how the echoed values are structured for comparison.

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, purpose front-loaded, followed by the caller obligation and the security caveat. Every clause carries operational weight and nothing is padding.

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?

Despite no output schema, the description enumerates what comes back (echoed nonce, Intel TDX quote, optional NVIDIA evidence, debug-mode state, signing-key binding), covering the return shape for the agent. Combined with the auth and verification notes, an agent has enough to invoke and interpret 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?

Schema description coverage is 100%, with both 'model' and 'nonce' fully documented in the schema (including the 64-hex-char pattern that the description restates as '32-byte'). The description echoes the schema rather than adding syntax or format detail beyond it, so the baseline 3 is appropriate.

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 (hardware-attestation evidence for a TEE-capable text model), so an agent knows exactly what the tool returns. It does not, however, differentiate itself from the closely related sibling venice_tee_signature, which an agent would need clarified before choosing between them.

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 implied through the freshness requirement ('must supply a fresh 32-byte nonce') and the verification chain 'before trusting the key', which tells the agent this is a pre-trust evidence step. There is no explicit when-to-use vs. when-not, and no routing to the sibling venice_tee_signature, 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine behavioral context beyond that: the tool 'only returns the provider payload' (it does not perform verification for you) and 'No authentication required'. These are meaningful traits not present in the structured fields.

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 core action before the verification caveat and auth note. Every sentence carries distinct information, though the middle clause is dense and could be slightly clearer.

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 exists, and the description compensates by explaining that it returns only the provider payload. Combined with well-documented params and the verification requirement, an agent has enough to call and interpret it; only the exact payload shape is left unspecified.

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 both parameters (model and request_id) are fully documented in the schema, including their provenance. The description adds no syntax or format detail beyond what the schema already provides, so 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 specific verb (Fetch) and resource (the enclave signature for a completed TEE text-model chat request), and ties the operation to the sibling attestation flow by noting the signature must be checked against a 'separately verified attestation'. An agent can distinguish this from venice_tee_attestation and from the chat tools without opening a 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?

Clearly implies the context of use ('for a completed TEE text-model chat request') and states a hard prerequisite (the caller must verify against a separately verified attestation). It does not explicitly name venice_chat or the attestation tool as the required predecessors, but the workflow is inferable.

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?

The description adds genuinely useful behavior beyond the annotations: the URL is fetched server-side, the file is sent as multipart/form-data, and it accepts either x402 wallet auth (no Venice account) or an API key. Those auth and transport details are exactly what an agent needs and are not in the structured fields. It does not explain the readOnlyHint=false implication (no persistent state created) or rate/size limits.

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, front-loaded with the action, then the mechanism, then the auth options. Every sentence carries information; only the auth sentence could arguably 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?

For a single-parameter tool with no output schema, the description covers input and auth adequately but never says what comes back (plain text, markdown, per-page structure) or what happens on an unsupported/failed fetch. Those omissions are the main remaining 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?

There is one parameter at 0% schema description coverage, so the schema gives only 'string' + uri format. The description clarifies that the value is the document URL and that the server fetches it, which adds real meaning, but it does not state supported URL schemes, size limits, or whether authenticated URLs work.

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 ('Extract text from a document URL'), and the title enumerates supported formats (PDF/DOCX/EPUB/PPTX/XLSX), which separates it from venice_web_scrape and the other media-generation siblings. It stops short of explicitly naming which sibling to prefer for non-document input, so it is clear but not sibling-routing.

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 implied by the resource type: an agent can infer this is for document files rather than web pages or images. There is no explicit when-to-use/when-not guidance and no alternative named (e.g., venice_web_scrape for HTML pages), so the routing decision 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?

Annotations only declare a generic mutation/non-idempotent profile with no side-effect detail. The description adds high-value behavioral context beyond annotations: it discloses that streaming=true does NOT emit incremental MCP chunks because the tool buffers the complete audio, and it documents dual auth paths (x402 wallet with no Venice account vs API key). These are exactly the non-obvious traits an agent needs.

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 sentences, front-loaded with the core purpose and then the two highest-value caveats (streaming buffering, auth options). Dense but every sentence earns its place; no filler or tautology.

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 exists, so the description should hint at return shape and it does implicitly ('returns one complete audio result'). Combined with the streaming caveat and auth coverage, it is nearly complete for a TTS tool. Minor gap: it never states the default response format or expected output container.

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 57%, above the threshold where the schema alone is deemed sufficient, so a baseline of 3 applies. The description reinforces the streaming semantics already noted in the schema and mentions the emotion-tag input syntax, but adds no detail on model, speed, temperature, or response_format 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 and resource ('Convert text to speech') and immediately differentiates scope by listing distinctive capabilities (cloned voices, emotion tags). An agent can distinguish this from siblings like venice_asr (the inverse task) and venice_voice_clone 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 description implies usage via capabilities (cloned voices, emotion tags, streaming) but never states when to use this tool versus alternatives such as venice_asr or venice_music_generate, nor any prerequisite conditions. Usage context is left to inference from the capabilities listed.

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 already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds useful context beyond them: removal is reported only when Venice confirms success, and auth can be x402 wallet (no Venice account) or API key. These are valuable behavioral/auth details not carried by the annotations.

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

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

Three tight sentences with zero waste; the core action is front-loaded and the confirmation/auth notes follow. Appropriately sized for 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?

No output schema exists and the destructive nature makes behavioral detail important; the description covers auth and confirmation semantics well. However, it leaves both parameters completely unexplained and gives no return/error detail, so it is only adequate for a destructive two-param 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 both parameters (queue_id, model) are undocumented in the schema. The description mentions neither, so it fails to compensate for the coverage gap. An agent gets no semantic help on what queue_id or model must contain.

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: 'Mark a completed video as downloaded and delete server-side media.' This clearly distinguishes the cleanup action from siblings like venice_video_status and venice_video_generate. It is clear but does not explicitly name or contrast a sibling.

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 phrase 'a completed video' implies the tool is used after a video finishes and has been downloaded, but there is no explicit when-to-use or when-not guidance and no named alternative such as venice_video_status for checking status first. Usage is implied rather than 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?

Goes well beyond the annotations: it discloses the return shape { model, queue_id }, the polling workflow, that x402 wallet auth works without a Venice account, the NSFW/uncensored posture, and that Seedance may reject detectable persons outright. It also clarifies that consent flags are defensive compatibility, not a policy bypass—material behavioral context the minimal annotations do not carry.

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

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

Front-loads the purpose and model list, then layers auth, return shape, and the consent caveat. The final consent NOTE is dense but earns its place given the nested const-true schema; a small amount of model-name listing is redundant but tolerable.

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 19-parameter, no-output-schema tool, the description supplies the missing return contract and polling flow, which the schema cannot. Combined with 89% parameter coverage, an agent has enough to call it, though cost/quote routing (venice_video_quote) and sync-vs-queue alternatives are 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 coverage is 89%, so the schema already documents nearly every parameter including duration enums, consents nesting, and URL fields. The description largely restates the duration-format and consent guidance found in the schema, adding little syntax or format meaning beyond it. Baseline 3 is appropriate.

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 ("Queue a video generation") and immediately names the poll counterpart venice_video_status, so the agent can distinguish it from the status/complete siblings. Enumerating the supported model families and example ids makes the scope concrete.

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 clear operational routing: poll with venice_video_status and inspect model-specific duration via venice_model_details, plus explicit sequencing for consent flags. It does not say when to prefer this over venice_video_complete or other generation siblings, so it stops short of full when/when-not coverage.

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 already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds two genuinely useful facts beyond that: no authentication is required, and the call happens before queuing (so it does not consume/enqueue a job).

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, front-loaded with the core purpose and the pre-queue constraint. No filler or redundancy.

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 two-parameter, read-only quote tool this is nearly complete. The one gap is that no output schema exists and the description does not hint at what the quote returns (e.g., credit/cost fields), which an agent may want to know before parsing 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 100%, so both parameters (model, duration) are fully documented in the schema itself. The description adds no format, enum, or constraint detail beyond it, which is the correct baseline when the schema does the work.

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 (get a price quote) and resource (video generation), with the temporal qualifier 'BEFORE queuing' that separates it from venice_video_generate. The sibling venice_audio_quote confirms the quote-then-generate pattern, and this tool is clearly the video variant.

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?

'BEFORE queuing' tells the agent this is a pre-flight step, which implies it should be called prior to venice_video_generate. It gives clear context but never names the alternative tool explicitly or states when a quote is unnecessary.

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 annotations already declaring idempotentHint=true and destructiveHint=false, the description adds real context: the POST endpoint and body shape, the different completion payload forms, VPS/Grok Imagine Private URL-reuse behavior, and that delete_media is ignored for download_url results. Auth modes (x402 wallet vs API key) are explicitly disclosed.

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 opening line is front-loaded and useful, but the VPS/Grok Imagine sentence is dense and hard to parse, and the endpoint/auth details read like implementation notes rather than agent-facing guidance.

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, so the description correctly takes on the burden of describing return values (in-progress JSON, embedded base64 MP4, or download_url link) and auth requirements. It covers most of what an agent needs, with minor gaps around polling cadence and the transition to venice_video_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?

Schema coverage is 100% and the schema descriptions already explain model, queue_id, download_url, and delete_media_on_completion in detail. The description largely restates those semantics, so the baseline of 3 applies despite the surrounding workflow context.

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: check status of a queued video job, with named return modes (JSON progress, base64 resource, download_url). It is clearly distinct from venice_video_generate, though it never explicitly contrasts itself with the sibling venice_video_complete.

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 implied through the workflow (queue via venice_video_generate, then poll here; the VPS case explains when download_url matters). However, it never states when to use this versus venice_video_complete or when to stop polling, so the agent must infer the boundaries.

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 only give generic flags (readOnly=false, destructive=false, idempotent=false). The description adds real behavioral context beyond them: the list action is auth-free, the create action hits POST /v1/audio/voices, the return is a `vv_<id>` handle, and both x402 wallet auth and API key are supported. It omits irreversibility/cost of cloning and any rate-limit detail.

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

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

Front-loads the purpose in the first clause, then walks action-by-action, then downstream usage, then auth. Dense but every sentence is functional; a slight trim of endpoint detail would tighten it further.

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 two-action tool with no output schema, the description covers both actions, the auth model, and the create return handle. The 'list' return is only described loosely ('live per-model voice metadata'), so a consumer still guesses at the shape, but nothing needed to call it is missing.

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 baseline is 3, but the description adds a non-obvious semantic constraint absent from the schema: the cloned voice must be paired with the SAME model, and it reiterates sample_url's action-scoped requirement. That pairing rule is the kind of guidance the schema cannot express.

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 ('Discover or clone TTS voices') and then disambiguates its two internal actions with distinct verbs ('list' reads metadata, 'create' uploads a sample). An agent can distinguish this from venice_tts or venice_list_models without opening a 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?

Explicitly ties each action to its precondition ('create requires sample_url') and closes the loop by telling the agent to pass the returned handle to venice_tts with the same model. It names a related sibling but stops short of stating when NOT to use this tool versus venice_list_models.

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 already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely useful context the annotations do not: dual auth via x402 wallet (no Venice account required) or API key. It does not disclose failure behavior or rate limits.

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

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

Two short sentences with no filler, and the core action is front-loaded before the auth detail. Efficient, though it could have folded in the format options at no extra length.

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 two-parameter scrape tool with no output schema, the auth disclosure is a real plus, but the description omits the non-markdown output formats, error/rate-limit behavior, and any note on external-resource variability implied by openWorldHint=true. 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 0%, so the description must carry the parameter burden. It only mentions markdown output, which corresponds to one enum value, and says nothing about the html/text alternatives the format parameter offers, nor any constraints on the URL. The url parameter is self-evident but format is under-explained.

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 (Scrape) and resource (one URL) plus the output form (markdown text). The word 'one' implicitly distinguishes it from the sibling venice_web_search, but the sibling is never named, so an agent gets a clear purpose without explicit differentiation.

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 explains authentication options but gives no when-to-use guidance or alternatives, e.g. when to scrape a single URL versus calling venice_web_search. The agent must infer the selection criteria 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?

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false), so the bar is lower, yet the description still adds real context: Zero Data Retention, proxying/anonymization, and that no Venice account is needed with x402 wallet auth. It does not explain why readOnlyHint is false for a search, which would be worth clarifying given the sibling read tools.

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 sentences, no filler, and the operation and provider default are front-loaded before the return-format and auth details. Every sentence carries distinct information.

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 correctly steps in to say results contain titles, URLs, snippets, and dates, and it documents both auth routes. Only the undocumented limit/query parameters keep it from being fully 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?

Schema coverage is only 33%, so the description should compensate, but 'limit' and 'query' get no mention. It does add provider trade-off framing (brave=ZDR, google=proxied/anonymized), though that largely restates the enum description already 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 specific verb and resource ('Search the web') plus the two backing providers, so the agent knows exactly what it does. It does not distinguish itself from the nearby sibling venice_web_scrape, which is the main ambiguity.

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?

It signals the Brave-is-default/Zero-Data-Retention choice and the two auth paths, which is implied usage guidance. But it never states when to pick this over venice_web_scrape or when the Google provider is preferable beyond a terse anonymization note.

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 already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: API key auth is rejected and the wallet must match the SIWX-authenticated identity. It does not describe response shape or error behavior, but the auth constraint is the key 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?

Three tight sentences with no filler: purpose first, then the auth constraint and identity-match requirement front-loaded as the operative caveats.

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 single-param read tool with no output schema, the description covers purpose, auth mode, and identity matching. It could briefly note the returned balance unit/format, but nothing essential for correct invocation is missing.

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 the single path parameter. It specifies the accepted address families (EVM or Solana) and the identity-match constraint, adding real meaning beyond the bare pattern 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 specific verb (Check) and resource (prepaid x402 credit balance) scoped to EVM or Solana wallet addresses. This clearly separates it from sibling billing/x402 tools like venice_billing_balance and venice_x402_transactions.

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?

Explicitly declares SIWX-ONLY usage and that API key auth is rejected, plus the constraint that the path wallet must match the SIWX-authenticated wallet. It does not name a sibling alternative for API-key callers (e.g., venice_billing_balance), so it stops short of full when/when-not routing.

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 already declare readOnly/idempotent/non-destructive, but the description adds several things they cannot: it is an empty POST with no payment header, nothing is charged, no authentication is required, and signing occurs outside this server. That goes well beyond the safety profile.

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

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

Front-loaded with the core action and purpose, then the return fields, then the behavioral caveats. Every sentence carries information; only the parenthetical field list makes it slightly dense, 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?

With no output schema, the description carries the burden of describing the response and does so fully (accepted USDC options, Base/Solana, payTo, minimum base units, settlement timeout). An agent has everything needed to call and interpret it.

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 per the calibration the baseline is 4. There is nothing further for the description to disambiguate.

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 (x402 top-up payment requirements) and enumerates the exact payload fields returned (network, asset, payTo, minimum amount, settlement timeout). The agent can distinguish it from venice_x402_balance and venice_x402_transactions without opening any 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?

Frames the call as the discovery step before payment and clarifies that signing/PAYMENT-SIGNATURE submission happens outside the MCP server, which tells the agent where this tool's responsibility ends. It does not explicitly name an alternative or exclusion, so it falls just short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: SIWX-only authentication, API keys are rejected, and the path wallet must match the SIWX-authenticated wallet. It stops short of describing ordering, pagination, or result shape, so it is strong but not exhaustive.

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 and immediately followed by the hard constraint. Every clause carries information; nothing 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 read-only listing tool with no output schema, the description supplies purpose, auth model, and the wallet-matching rule. Missing only secondary details like ordering, default limit behavior, and pagination, which are minor for a tool of this complexity.

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

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

Schema description coverage is 0%, so the description must carry the burden. It partially compensates by explaining that the wallet is EVM or Solana (clarifying the address formats) and that it must match the authenticated wallet, but the limit parameter (1-100) and its effect on result size are never mentioned.

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 a precisely scoped resource (recent x402 top-up + debit transactions) qualified by wallet type (EVM or Solana). This cleanly separates it from sibling x402 tools like venice_x402_balance and venice_x402_top_up_info without needing to name them.

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 implied by the resource (fetch transaction history for a wallet), and the auth precondition narrows the audience, but there is no explicit 'use this instead of / in addition to' routing against venice_x402_balance or venice_billing_usage_history. Adequate but leaves the agent to infer the selection criteria.

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