Server Quality Checklist

Tool Scores

• venice_image_multi_editC
  2.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It does disclose that the tool 'Returns base64 PNG' and mentions auth options (x402 wallet, API key), which is useful. However, it doesn't state whether inputs are modified destructively, whether the operation is rate-limited, what happens on failure, or the output format details beyond base64. For an image mutation tool with zero annotation coverage, more behavioral disclosure is needed.

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

  Conciseness3/5

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

  The description is reasonably compact at two sentences and front-loads the core purpose. However, 'Operator preferences — default: flux-2-pro; also try: qwen-image' is loosely structured and reads as informal notes rather than clear guidance. The '2-8 input images' duplicates schema constraints. Content is dense but somewhat unstructured.

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

  Completeness3/5

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

  For a multi-input image editing tool with 4 params, no output schema, and no annotations, the description provides the core function and output format (base64 PNG) plus auth methods, which is helpful. But it omits key aspects: no parameter-level documentation, no distinction from venice_image_edit for single-image use cases, and no guidance on input image constraints (formats, sizes, hosted URLs). It's functionally adequate but leaves meaningful gaps for a complex multi-input tool.

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

  Parameters1/5

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

  Schema description coverage is 0%. The description mentions 'image_urls' implicitly via '2-8 input images' but provides no detail on image URL requirements (e.g., URL vs base64, hosting requirements, size limits). None of the 4 parameters (model, prompt, image_urls, aspect_ratio) receive explicit semantic explanation beyond what the schema's names and types convey. With 0% schema coverage and zero parameter documentation in the description, this is a critical gap.

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

  Purpose4/5

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

  The description clearly states a specific verb+resource: 'Edit multiple images together with a single prompt (multi-image composition / outpainting).' It distinguishes this from siblings like venice_image_edit (singular) and venice_image_generate. However, '2-8 input images' is redundant with the schema maxItems/minItems, and the edit types (composition/outpainting) could be differentiated more explicitly from venice_image_edit.

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

  Usage Guidelines3/5

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

  The description mentions no explicit alternatives or when-not-to-use guidance. It states 'Operator preferences — default: flux-2-pro; also try: qwen-image' which is model-selection guidance, not usage context versus alternatives. There's no mention of when to pick multi-edit over single-edit or generate beyond the implicit 'multi-image' implication.

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

• venice_music_completeB
  3.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses the auth modes (x402 wallet, API key) which is useful. However, for a completion/cleanup tool, it doesn't state whether the operation is idempotent, destructive, or irreversible once marked, nor what happens if called on a non-completed job. The auth disclosure is the main value-add, but behavioral side-effects remain unstated.

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

  Conciseness4/5

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

  Two sentences, concise and front-loaded with the purpose. Each sentence earns its place: the first states what it does and its role as a hook, the second covers auth requirements. No fluff or repetition. Could arguably add parameter guidance, but as written it's tight.

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

  Completeness2/5

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

  With no output schema, no annotations, and 0% param coverage, the description carries significant burden and falls short. It doesn't explain the lifecycle relationship (must follow venice_music_generate/status), error cases, idempotency, or what the response contains. For a tool that marks state ('downloaded'), knowing whether it's reversible or what happens on conflict would materially improve agent decision-making.

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

  Parameters2/5

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

  Schema coverage is 0% for both parameters (queue_id, model), and the description adds essentially no parameter information. The description doesn't explain what queue_id should contain (an identifier from a prior music_generate call) or what model refers to. With 0% coverage and no param elaboration in the description, the agent must infer meaning from parameter names alone, which is a significant gap.

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

  Purpose4/5

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

  The description uses a specific verb+resource: 'Mark a completed music job as downloaded.' It clearly states this is a cleanup hook and distinguishes it from generation/status tools by the 'completed' and 'downloaded' framing. Internal naming consistency (complete vs status/generate) is clear, though it doesn't explicitly name a sibling alternative.

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

  Usage Guidelines3/5

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

  Calling itself a 'cleanup hook' implies usage timing (after a job completes). 'Supports x402 wallet auth (no Venice account needed) and API key' adds auth context. However, it doesn't explicitly state when NOT to use this (e.g., not for checking status - use venice_music_status) or name alternatives, leaving usage boundaries somewhat 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.

• venice_voice_cloneB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden for behavioral disclosure. It discloses the multipart upload mechanism and the auth modes (x402 wallet, API key), which is valuable. However, it doesn't disclose side effects (does 'create' persist the clone? is it reversible? requires prior authorization?), failure modes, or constraints on sample audio (duration, size limits). For a mutation action like 'create' with zero annotation coverage, more behavioral detail is warranted.

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

  Conciseness3/5

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

  The description is reasonably compact but mildly redundant — the opening 'Manage TTS voices' is restated by the following sentences, and the line 'List built-in voices OR clone from a sample audio URL' repeats the action mechanism already explained. Front-loading the action mechanism is good, but the redundancy wastes space that could carry behavioral or usage detail. No clear structure break for the two distinct workflows.

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

  Completeness3/5

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

  With no output schema and no annotations, the description must cover behavior and return expectations, and it partially does (notes list returns static catalog). It clearly documents the two actions and auth. However, it fails to describe what 'create' returns (the cloned voice ID? status?), what happens with invalid audio, or the full scope of the multipart upload flow. For a dual-action tool with 3 interdependent parameters, it's adequate but leaves meaningful gaps around the 'create' workflow's outcomes.

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

  Parameters3/5

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

  Schema coverage is 100%, so all three parameters are documented in the schema itself. The description adds some value by clarifying the relationship between model and sample_url for action=create, and that action enum values map to behaviors. However, it doesn't add format-level detail beyond the schema (e.g., examples of valid sample_url formats, constraints on model values) beyond what's already in the schema's model description.

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

  Purpose4/5

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

  Description uses specific verbs ('list' returns the catalog, 'create' clones from a sample URL) and clearly identifies the resource as TTS voices. It distinguishes from the sibling venice_tts tool by noting this manages voice cloning/catalog, not speech generation. However, the two-sentence description reads somewhat repetitive ('Manage TTS voices' followed by re-explaining both actions), which slightly dilutes the purpose statement.

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

  Usage Guidelines3/5

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

  The description explains the two distinct actions (list vs create) and notes that list returns a static catalog because Venice exposes no list endpoint. It mentions x402 wallet auth and API key as supported auth methods, which is useful context. However, it doesn't explicitly state when to prefer this over venice_tts or other siblings, nor does it give exclusion guidance (e.g., 'use venice_tts for speech synthesis').

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

• venice_list_charactersB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It does state the authentication requirement (api-key only, no x402) which is a real behavioral constraint. However, it doesn't disclose pagination behavior, rate limits, or what the return structure looks like. The auth note is useful but the behavioral disclosure is incomplete.

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

  Conciseness5/5

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

  Two concise sentences with zero wasted words. The auth distinction is front-loaded and directly relevant. Every sentence earns its place.

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

  Completeness2/5

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

  For a 4-parameter tool with no output schema and no annotations, the description should provide more guidance. No mention of pagination behavior, default limit behavior, what 'tag' filters on, or response format. The auth disclosure is helpful but doesn't compensate for the lack of parameter guidance and return information. Multiple sibling character-related tools exist, so more disambiguation is needed.

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

  Parameters2/5

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

  Schema description coverage is 0% — the description explains NONE of the 4 parameters (tag, limit, offset, search). Each parameter's semantics are entirely undocumented. Names are somewhat self-explanatory (limit, offset, search), but 'tag' is ambiguous and none have type/format guidance beyond the schema. The description must compensate for the 0% coverage and does not.

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

  Purpose4/5

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

  Clear verb+resource ('List public Venice characters'). The tool's purpose is unambiguous and the scope ('public') is specified. It distinguishes itself from venice_list_models and other list tools by naming 'characters' specifically, though it doesn't explicitly contrast with siblings like venice_chat_with_character.

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

  Usage Guidelines3/5

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

  The description explains WHEN it applies vs alternatives in terms of auth: 'api-key only, no x402' and explicitly states 'this endpoint does not accept x402 wallet auth.' This is a meaningful usage constraint. However, it doesn't say when to choose this over venice_chat_with_character or how the two relate, leaving some ambiguity for the agent.

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

• venice_video_transcriptionsB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided the description carries the full burden. It mentions the auth paths (x402 wallet vs API key), which is useful behavioral context. However, it doesn't disclose limits like max video length, supported languages, whether the entire video is transcribed or a segment, or any cost/rate-limit implications. The 'transcript' nature implies a read-only outcome but this isn't explicitly confirmed.

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

  Conciseness4/5

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

  The description is a compact 3-sentence block that conveys the core action, operator preference, and auth options without waste. Each sentence earns its place. It could arguably merge some clauses, but nothing is verbose or redundant.

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

  Completeness3/5

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

  For a 2-param tool with no nested objects and no output schema, the description is reasonably complete: it names the source (YouTube), the outcome (transcript), and auth paths. Gaps remain: no explanation of response_format behavior, no stated limitations (video length, language), and no detail on operator preferences. This is adequate but not thorough for a transcription service where input size and format expectations matter.

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

  Parameters3/5

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

  Schema coverage is 50%, and the description describes the url parameter ('YouTube URL → text transcript') and references 'youtube-default' operator preference, adding modest context. However, the response_format param (enum: json/text) is in the schema but not described in the prose at all, and the description doesn't explain default responses or format differences. The description adds minimal value beyond what the schema already conveys.

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

  Purpose4/5

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

  The description clearly states the verb ('Transcribe') and resource ('YouTube video URL'), and specifies the output ('text transcript'). This distinguishes it from siblings like venice_asr (which likely handles different input types) and venice_video_generate (video creation, not transcription). However, it doesn't explicitly contrast with venice_asr or venice_text_parser, leaving slight ambiguity about which transcription tool to choose.

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

  Usage Guidelines2/5

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

  The description mentions 'Operator preferences — default: youtube-default' and 'Supports x402 wallet auth (no Venice account needed) and API key', which gives some context on auth options. However, it provides no when-to-use guidance, no exclusions versus venice_asr (which may also transcribe audio/video), and no indication of when to prefer this over alternatives. 'Operator preferences' is mentioned but not explained in a way an agent can act on.

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

• venice_ttsB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It adds useful context about supported features (cloned voices, emotion tags) and auth methods (x402 wallet, API key). However, it doesn't disclose output format details, latency, cost, rate limits, or whether voice cloning requires prior setup. The two overlapping sentence fragments about emotion tags are a minor transparency concern.

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

  Conciseness3/5

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

  The description is reasonably concise but somewhat disorganized and redundant. Sentence 1 states purpose and features; sentence 2 repeats the voice cloning + emotion tag point nearly verbatim; sentence 3 covers auth. The redundant middle sentence wastes space and could be merged, and the operator-preferences detail reads as internal context rather than end-user guidance.

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

  Completeness3/5

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

  For a TTS tool with 5 params, no output schema, and no annotations, the description covers core capability, key features, model defaults, and auth. But it omits practical details: typical output format default, how to discover available voices (though 'venice://voices' hint is there via schema), whether speed applies to all models, and behavior when input exceeds limits (schema handles maxLength but not truncation behavior). Adequate but with gaps.

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

  Parameters3/5

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

  Schema coverage is 40% (input and voice have descriptions; model, speed, response_format lack descriptions). The description adds some value by mentioning the default model and supported response concepts indirectly (emotion tags relate to input). However, it doesn't explain speed semantics (0.25-4 range meaning), response_format trade-offs, or how model selection works. Doesn't fully compensate for the coverage gap.

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

  Purpose4/5

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

  The description clearly states 'Convert text to speech' with a specific verb+resource. It distinguishes itself from siblings by highlighting unique features (voice cloning, emotion tags, x402 auth). However, it doesn't explicitly differentiate from venice_voice_clone, and the second sentence ('Voice cloning + emotion tags...') is somewhat redundant with the first.

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

  Usage Guidelines3/5

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

  The description provides useful default model preference ('default: tts-kokoro; also try: elevenlabs-tts') and auth options (x402 wallet vs API key). However, it doesn't explicitly state when to use this instead of alternatives like venice_voice_clone, venice_audio_quote, or venice_asr. No exclusions or when-not-to-use guidance.

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

• venice_web_searchB
  3.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses the Firecrawl backing, ranked results with snippets, auth requirements (x402 wallet without Venice account, or API key), and operator preferences. This is decent behavioral context but doesn't disclose rate limits, query limits, or return format details beyond 'ranked results with snippets.'

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

  Conciseness3/5

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

  The description is concise (3 sentences) but somewhat redundant — 'Firecrawl-backed' appears twice ('Search the web (Firecrawl-backed)' and 'Firecrawl-backed ranked results'). The operator preferences note is inserted awkwardly between the main statement and the ranking statement, disrupting flow.

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

  Completeness3/5

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

  For a web search tool with only 2 simple parameters and no output schema, the description conveys the core purpose (Firecrawl web search, ranked/snippeted results) and auth requirements. Missing details include pagination/result count behavior, whether 'limit' caps total results, regional/language controls, and what happens on no results. Adequate but not rich.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It doesn't describe the 'query' parameter at all, though the purpose is implied by the tool name. The 'limit' parameter is also undocumented in description. However, with only 2 parameters (query and limit), the schema's JSON property names are fairly self-explanatory, mitigating the gap.

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

  Purpose4/5

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

  States a specific verb+resource: 'Search the web (Firecrawl-backed).' It clearly indicates web search functionality distinct from siblings like venice_web_scrape or venice_chat. However, it doesn't explicitly contrast with sibling search-like tools, so not a 5.

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

  Usage Guidelines3/5

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

  Implies usage for web searching and mentions operator preferences and auth modes (x402 wallet, API key). However, it doesn't explicitly state when to use this vs venice_web_scrape or other alternatives, and the mention of 'operator preferences' is vague without explaining what those preferences are or how they affect results.

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

• venice_asrB
  3.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It does disclose key behaviors: server-side URL fetching, multipart file forwarding, default model selection, x402 wallet support (no Venice account needed), and API key option. This is good transparency about how the tool operates under the hood. Minor gaps: no mention of mutation/side effects (unlikely for this type) or error behavior.

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

  Conciseness4/5

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

  Three sentences, front-loaded with the core purpose ('Transcribe audio.') followed by operational details. No wasted words. Sentence order is logical: purpose → transport mechanism → auth/defaults. Efficient and readable.

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

  Completeness3/5

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

  For a single-required-param tool with no output schema, the description covers the core function well. However, the 'response_format' enum (srt, vtt, verbose_json) implies meaningful output variations that the description doesn't explain, and supported input audio formats/lengths are not mentioned. Adequate for a basic transcription call but leaves the agent guessing on format semantics and input constraints.

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

  Parameters2/5

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

  Schema description coverage is 0% at the schema level, and the description adds virtually no parameter-level detail. It mentions the default model ('openai/whisper-large-v3') which helps contextualize the 'model' param, but provides no guidance on 'language', 'response_format' (despite an enum offering srt/vtt/verbose_json options), or 'audio_url' format expectations. With 4 params and 0% schema coverage, the description should compensate but doesn't significantly.

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

  Purpose4/5

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

  Clear verb+resource: 'Transcribe audio.' Specific and distinguishes from siblings like venice_tts (speech synthesis) and venice_video_transcriptions. Mentions the default model and key transport behavior (URL fetched server-side, forwarded as multipart). Purpose is clear, though it doesn't strongly contrast against venice_video_transcriptions which appears to be a related transcription tool.

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

  Usage Guidelines3/5

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

  States it fetches URLs server-side (implicit hint about how to supply audio). Mentions operator default model and auth options (x402 wallet, API key). However, no explicit guidance on when to use this vs venice_video_transcriptions, or any prerequisites/limitations such as file size or supported audio formats. Usage context is implied but not explicitly scoped.

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

• venice_image_editB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose output format (base64 PNG) and supports x402 wallet auth without a Venice account — useful. However, it doesn't mention rate limits, image size constraints, prompt sensitivity, or whether edits are destructive to the source — for an edit tool these would add meaningful context.

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

  Conciseness4/5

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

  Three concise sentences covering purpose, output, model options, and auth. Front-loaded with the core purpose. The operator-preference and auth details are useful additions that earn their place, though the structure could be slightly tighter.

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

  Completeness3/5

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

  With no output schema and no annotations, the description provides reasonable context for a moderately complex image-editing tool. It explains output format, model defaults, and auth path, but with 5 parameters and undocumented fields like safe_mode, it leaves gaps that a complete offering would address.

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

  Parameters3/5

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

  Schema coverage is 40% (model and image_url have descriptions; prompt, safe_mode, aspect_ratio do not). The description adds value by naming model options and the default, but doesn't explain safe_mode semantics or aspect_ratio supported values beyond the schema enum. Partially compensates for the coverage gap but leaves undocumented parameters unexplained.

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

  Purpose4/5

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

  The description states the tool edits an image with a prompt and returns base64 PNG — a clear verb+resource+output statement. It distinguishes capability from sibling tools like venice_image_generate and venice_image_remove_bg by noting it modifies an existing image, though it doesn't explicitly name a differentiating sibling.

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

  Usage Guidelines3/5

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

  The description mentions operator preferences for models (default firered-image-edit, alternative qwen-image-edit) and highlights x402 wallet auth as an option, providing useful context. However, it doesn't explicitly state when to use this vs venice_image_multi_edit or venice_image_generate, nor any exclusions.

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

• venice_crypto_rpcA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses authentication options (x402 wallet auth no Venice account, API key) and how to list available networks via GET endpoint, which is useful. However, it doesn't disclose what happens on errors, rate limits, response format, or any side effects. Given the zero annotation coverage, a 'proxy' tool safely implies read-only behavior but this is not explicitly confirmed, preventing a higher score.

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

  Conciseness4/5

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

  The description is a compact 3 sentences that pack substantial information: the general purpose, network list method, specific supported chains, and auth options. Every sentence earns its place. Minor redundancy exists (networks listed twice), but the structure is efficient and front-loaded with the core purpose. Not quite a 5 due to the slight repetition of network names across sentences.

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

  Completeness3/5

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

  With a proxy tool that has 3 parameters (one undocumented array type) and no output schema, the description provides the core capability and auth model but omits response format, error handling, and clear parameter semantics for rpc_params/rpc_method. The GET endpoint for listing networks is a helpful discovery mechanic. The description is adequate for basic use but leaves the agent to guess at parameter formats and return types, which is a meaningful gap for a tool where responses vary by RPC method.

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

  Parameters2/5

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

  Schema coverage is only 33%, and the description adds no parameter-level detail beyond what the schema provides. The description mentions the network naming convention ('base-mainnet' NOT just 'base') which is echoed in the schema's network field description, adding marginal value. But rpc_params (an array with no item schema) is completely undocumented in both schema and description, and rpc_method also lacks explanation of accepted values or format. With 67% of coverage missing, the description fails to compensate.

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

  Purpose5/5

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

  The description clearly states it proxies JSON-RPC calls to supported blockchain networks with specific verbs (proxy, list) and concrete resources (eth_call, eth_blockNumber, specific network names). It explicitly lists example networks and distinguishes the general RPC proxy role. The 'Proxy a JSON-RPC call' verb+resource is specific and unambiguous, and the supported methods and networks are clearly enumerated.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives. It does provide concrete examples of methods (eth_call, eth_blockNumber) and networks (base-mainnet, ethereum-mainnet, etc.), which implies usage context. However, there are no exclusions or explicit guidance about when NOT to use it, nor any mention of alternative tools for similar operations. Given the entirely different sibling tools (all non-crypto focused), the lack of explicit alternative guidance is somewhat mitigated, hence a 3.

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

• venice_video_completeA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It explicitly discloses the destructive behavior ('deletes server-side media') twice, which is a key behavioral trait. It also mentions auth methods (x402 wallet, API key). However, it doesn't disclose what happens to the queue record, whether deletion is reversible, or error behavior if called before download completes.

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

  Conciseness3/5

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

  The description is short but contains redundancy: 'deletes server-side media' appears twice ('deletes server-side media' and 'removes server-side media'), and the cleanup-hook concept is repeated. The auth info is useful but the duplication of the destructive behavior wastes a sentence in an already short description.

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

  Completeness3/5

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

  With no annotations, no output schema, 0% parameter coverage, and a destructive side effect, the description should disclose more about preconditions (e.g., video must be in completed state) and post-conditions. The duplication of the deletion statement could have been replaced with lifecycle preconditions or return behavior info.

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

  Parameters3/5

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

  Schema description coverage is 0%, so parameters are completely undocumented at the schema level, and the description does not describe what 'queue_id' or 'model' mean or how they should be formed. The description adds no parameter-level meaning despite the 0% coverage gap, leaving the agent to infer from names.

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

  Purpose5/5

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

  The description clearly states the tool marks a completed video as downloaded and deletes server-side media. It uses a specific verb-action pairing and identifies it as a 'cleanup hook'. It distinguishes from siblings like venice_video_status and venice_video_generate by focusing on the completion/cleanup lifecycle step.

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

  Usage Guidelines3/5

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

  The description implies this is a cleanup hook to be called after downloading a video, and mentions it supports x402 wallet auth and API key. However, it doesn't explicitly state when to use this vs the sibling venice_music_complete or other completion tools, nor does it spell out that it should only be called after the video is fully downloaded.

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

• venice_video_quoteA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It adds 'No authentication required' (useful context) but doesn't disclose what the quote returns (cost amount, currency, validity period), whether pricing is per-second/per-duration, or how it handles unknown models. For a quote tool where the output format is a key mystery (no output schema), this is a significant gap.

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

  Conciseness4/5

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

  Three short, focused sentences that each earn their place: purpose, when-to-use guidance, and authentication note. No wasted words. Could be slightly better structured but is efficient and readable.

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

  Completeness3/5

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

  The tool has no annotations and no output schema, so the description should compensate. It covers purpose and usage clearly but omits what the quote response looks like, cost units, and edge-case behavior (e.g., unknown model IDs). For a 2-param tool with good schema coverage, it's adequate but leaves the most important unknown—what the quoted price output contains—undocumented.

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

  Parameters4/5

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

  Schema coverage is 100%, so the schema documents both parameters well. The description adds the crucial context that duration is model-specific (aligning with the schema's 'model-specific string enum' note). While the description doesn't add much param detail beyond the schema, the schema itself is already comprehensive with examples, earning a baseline-above-3.

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

  Purpose4/5

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

  The description clearly states it provides a price quote for video generation and specifies the timing ('BEFORE queuing'). The verb 'Get a price quote' plus the resource 'video generation' is specific. It distinguishes from venice_video_generate by emphasizing the pre-queue quoting purpose, though it doesn't explicitly contrast with venice_audio_quote as a sibling.

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

  Usage Guidelines4/5

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

  The description gives explicit usage guidance: 'Always quote-generate before queue when model pricing is unknown.' This is a clear 'when to use' instruction tied to a condition (unknown pricing). It doesn't spell out when NOT to use it, but the conditional phrasing sufficiently implies usage context.

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

• venice_web_scrapeA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It does mention the firecrawl-default operator preference and x402 wallet auth (no Venice account needed), which is useful. However, it doesn't disclose that this is a read-only operation, what happens on failed scrapes, or the output format beyond 'markdown text'. The description covers auth but lacks depth on failure behavior and 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.

  Conciseness4/5

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

  The description is compact at three sentences, front-loading the core purpose first. The second sentence ('One URL → markdown text') is somewhat redundant with the first but reinforces scope. No padding or wasted words.

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

  Completeness3/5

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

  This is a fairly simple tool with only 2 parameters and no output schema, so completeness requirements are moderate. However, with 0% schema coverage, the description should explain the format parameter options (html, text) and disclose behavioral traits for a network-fetching tool (read-only, auth, failure modes). It covers auth but leaves format semantics and error behavior undocumented.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter documentation. The description covers the 'url' parameter implicitly (one URL) and mentions format output (markdown) but doesn't explain the 'format' enum options (html, text) or what the firecrawl-default operator preference means for format selection. The description adds minimal value over the schema.

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

  Purpose5/5

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

  The description clearly states the tool converts one URL into markdown text, which distinguishes it from its sibling tools like venice_web_search (searching vs. scraping) and venice_text_parser (parsing existing text vs. fetching a URL). The verb+resource (scrape one URL) is specific and clear.

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

  Usage Guidelines3/5

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

  The description notes the operator preferences default (firecrawl-default), which is useful context. However, it doesn't explicitly state when to use this tool vs. alternatives like venice_web_search or discuss limitations (e.g., which URLs work, rate limits). The 'one URL' constraint implies single-page scraping but no exclusions or alternative guidance is given.

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

• venice_audio_quoteA
  3.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosure. It mentions 'No authentication required', which is a meaningful behavioral trait. It implies a read-only, non-mutating operation ('quote BEFORE queuing') which signals this will not trigger generation or incur charges. For a non-mutating pricing tool, this disclosure is reasonably adequate.

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

  Conciseness3/5

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

  The description is short, but it contains redundant restatement: 'Get a price quote for a music generation BEFORE queuing' repeats the idea in 'Pre-flight price quote for music generation.' The 'Useful for budgeting' adds mild value. Three short sentences where two would suffice. Concise but with redundancy.

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

  Completeness4/5

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

  For a quote tool with no output schema, the description conveys the essential purpose (pre-flight pricing) and key context (no auth). The 3 parameters are adequately named in the schema. Given the tool's relative simplicity as a non-mutating quote endpoint, this is reasonably complete, though edge case documentation (interaction of character_count vs duration_seconds) would strengthen it.

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

  Parameters3/5

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

  Schema coverage is 67% (2 of 3 parameters described in schema). The description adds no parameter-level detail beyond the schema. The description does indicate the model is what's keyed to pricing, but doesn't explain edge cases around character_count vs duration_seconds or whether both can/should be provided together. With 67% coverage and no compensation from the description, this is near the baseline.

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

  Purpose4/5

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

  The description clearly states it provides a price quote for music generation before queuing, with 'Get a price quote' + specific resource. It distinguishes itself from the related sibling venice_music_generate by making clear this is a pre-flight budgeting action. Slight deduction for repetition between 'Get a price quote... before queuing' and the redundant follow-up sentence 'Pre-flight price quote for music generation'.

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

  Usage Guidelines3/5

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

  It implies when to use it ('BEFORE queuing', 'Useful for budgeting'), which provides context that this is a pre-flight step for venice_music_generate. However, it doesn't explicitly contrast with alternatives or state when NOT to use it, though sibling tools like venice_music_generate, venice_video_quote exist. 'No authentication required' adds some usage context but no explicit exclusions.

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

• venice_image_remove_bgA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the auth mechanism (x402 wallet auth, no Venice account needed, API key) and the default operator, but does not explain whether there are rate limits, quota considerations, potential model costs, or error behaviors when the operation fails.

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

  Conciseness4/5

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

  The description is three sentences and front-loads the core operation (remove background, returns transparent PNG base64) immediately. The auth details and operator preference are relevant supplemental context. Minor waste: mentioning 'Operator preferences' as a header-like phrase adds a little formality without much added value.

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

  Completeness3/5

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

  For a single-parameter tool with no output schema and no annotations, the description is adequate but not rich. It covers output format and auth but omits input constraints (image size, format) and any behavioral caveats about quality or failure modes, which could matter to an agent selecting this tool.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description should compensate for documenting the single parameter (image_url). It does not explicitly mention the parameter or its format/expectations. However, with only one required parameter that is a simple URI, the description's omission is less damaging than it would be for a multi-parameter tool.

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

  Purpose5/5

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

  The description clearly states the verb (Remove), resource (image background), and the specific output format (transparent PNG base64). This distinguishes it well from siblings like venice_image_upscale and venice_image_edit, all of which operate on images but do different transformations.

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

  Usage Guidelines3/5

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

  The description indicates operator preferences (bria-remove-bg) and auth options, which is useful context. However, it does not explicitly state when to choose this tool over venice_image_edit or venice_image_multi_edit, nor does it mention limitations (e.g., input image requirements, file size limits).

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

• venice_music_generateA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses auth requirements (x402 wallet, API key), NSFW policy, and that it returns {model, queue_id} with polling via venice_music_status. This is meaningful behavioral context, though it doesn't fully describe error behaviors, rate limits, 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.

  Conciseness3/5

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

  The description is dense with useful operational details but somewhat rambling, mixing model lists, operator preferences, and auth info in a somewhat unstructured flow. It's informative but could be tidier with clear separation of concerns. The return-value note is valuable and front-loaded reasonably well.

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

  Completeness4/5

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

  Despite no output schema and minimal schema param coverage, the description covers model selection, auth methods, return format, polling flow, and policy boundaries (NSFW). For a queue-submission tool of moderate complexity, this is reasonably complete for agent guidance. It could add error handling and quota/rate-limit notes but is close to sufficient.

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

  Parameters3/5

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

  Schema description coverage is only 20%, meaning the schema documents very few parameter meanings. The description compensates somewhat by explaining model selection semantics (which models map to which use cases), but it doesn't add detail on prompt, lyrics, instrumental, or duration_seconds parameters beyond what minimal schema descriptions provide. Some help, not comprehensive.

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

  Purpose4/5

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

  The description states the tool 'Queue music generation' with a specific verb and resource, clearly indicating this is the queue-submission step for music generation. It distinguishes from siblings like venice_music_status and venice_music_complete by noting the return value and polling flow. However, it doesn't explicitly contrast with venice_music_status/complete within the text, relying on context.

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

  Usage Guidelines4/5

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

  The description provides model selection guidance including operator preferences (default ace-step-15), use-case-specific recommendations (Elevenlabs for vocal, MMaudio for stem separation), and notes about NSFW and auth paths (x402 wallet, API key). It clearly communicates when this is appropriate though it doesn't explicitly name alternatives or when-not-to-use scenarios beyond the model guidance.

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

• venice_video_statusA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses POST method, endpoint, return values (PROCESSING or COMPLETED), and authentication methods (x402 wallet auth, API key). This is reasonably rich behavioral context. However, it doesn't disclose rate limits, poll intervals, or whether retries are advised, and doesn't explain the delete_media_on_completion behavior.

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

  Conciseness4/5

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

  Three sentences covering purpose, status enum, endpoint, and auth — efficient and front-loaded. The first sentence clearly states the action. Minor redundancy: mentioning 'PROCESSING or COMPLETED' twice and endpoint twice slightly hurts conciseness, but overall it's compact.

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

  Completeness3/5

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

  For a status-check tool with no output schema and no annotations, the description provides solid context: status values, endpoint, auth methods. It's missing details on the undocumented delete_media_on_completion parameter and doesn't describe the exact response structure (does it return the media once COMPLETED?). It's adequate but leaves gaps, especially for a tool sitting in a larger video workflow with generate/complete siblings.

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

  Parameters3/5

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

  Schema coverage is 67% — model and queue_id are documented. The description reiterates that queue_id comes from venice_video_generate and model must be the same one used to queue, which adds useful cross-tool context. However, delete_media_on_completion (the undocumented param) is given no description anywhere, and the description doesn't explain how model relates to the generation call beyond 'same as used to queue'.

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

  Purpose4/5

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

  The description states a clear verb+resource: 'Check status of a queued video job' with the status enum (PROCESSING, COMPLETED) and endpoint path (POST /v1/video/retrieve). It clearly distinguishes the retrieve/status tool from generate and complete siblings. However, it doesn't explicitly differentiate from venice_video_complete, and the title 'Retrieve / Status' is slightly ambiguous about whether it retrieves the output or checks status.

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

  Usage Guidelines4/5

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

  The description makes the usage context clear: it's for checking status of a queued job, uses queue_id returned by venice_video_generate. It implies when to use it relative to the generate flow. However, it doesn't explicitly state when NOT to use it or name alternatives like venice_video_complete, so it lacks explicit exclusions.

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

• venice_chat_with_characterA
  3.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the key behavioral nuance (API-key vs x402 distinction), operator model preferences, and the NSFW/uncensored nature of the tool. This is meaningful context beyond what the schema exposes.

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

  Conciseness4/5

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

  Three compact sentences, all information-bearing, no fluff. Front-loads the core purpose. Slightly dense toward the end with the operator-preference list, but acceptable.

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

  Completeness4/5

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

  For a chat-completion tool with self-explanatory parameters and no output schema, the description covers purpose, inputs, auth nuance, and model defaults well. It doesn't describe return format, but given the tool type that's a minor gap.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It does clarify character_slug usage and gives model guidance, but leaves max_tokens, temperature, and messages semantics entirely to the schema. The schema itself is fairly self-explanatory for these, so partial credit is warranted.

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

  Purpose4/5

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

  The description clearly states the verb+resource: 'Chat with a Venice character by slug.' It references character_slug from list_characters, anchoring the primary input. However, it doesn't strongly differentiate from sibling venice_chat, which is a close analog for general chat completions.

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

  Usage Guidelines3/5

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

  The description provides practical context: it notes the character lookup is API-key-only while chat supports x402, and recommends model preferences (default and alternative). However, it doesn't explicitly state when to choose this tool over venice_chat or venice_responses, or provide exclusions.

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

• venice_responsesA
  3.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and it does a solid job: discloses uncensored/NSFW behavior, x402 wallet auth capability (no Venice account needed), API key support, and tool-use loop support. This is meaningful behavioral context beyond what any schema or annotation provides. Slightly limited by not describing rate limits or return format, but strong for an unannotated tool.

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

  Conciseness4/5

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

  The description is reasonably concise at ~5 sentences and front-loads the key purpose. Some redundancy exists (mentioning 'OpenAI Responses API' twice and repeating OpenAI-compatibility), but overall it packs useful info without bloat. Slight repetition reduces this from a 5.

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

  Completeness4/5

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

  For a tool with no output schema and 25% param coverage, the description provides decent operational context: model defaults, NSFW policy, auth options, and tool-use capability. However, it doesn't explain return value structure, streaming, error behavior, or the input schema nuances for tool-calling messages — gaps an agent would benefit from given the 'tool support' claim.

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

  Parameters3/5

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

  Schema description coverage is only 25% (only 'input' is documented). The description compensates partially by clarifying the input can be single-turn or multi-turn with tool support, and mentions the model preference defaults, but doesn't clarify temperature semantics, max_output_tokens constraints, or how tool use is specified in the message array. Minimal value added beyond schema for the undocumented params.

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

  Purpose4/5

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

  Description clearly states this is an 'OpenAI-compatible Responses API' supporting 'Single-turn or multi-turn with tool support.' It distinguishes from siblings by highlighting the OpenAI Responses API compatibility and agentic tool-use loop, which differentiates from venice_chat. However, it doesn't explicitly contrast with venice_chat, only implying the distinction.

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

  Usage Guidelines3/5

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

  The description notes model preferences (default minimax-m3-preview, also try qwen-3-7-max) which aids model selection, and mentions premium/uncensored behaviors. However, it never explicitly states when to use this tool vs venice_chat or when NOT to use it, leaving the agent to infer the boundaries from the sibling list and the description's own framing.

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

• venice_music_statusA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden. It usefully discloses the async behavior (returns until COMPLETED), the endpoint, and both auth methods (x402 wallet auth, API key). However, it doesn't explain what happens on failure, retry semantics, or the response structure of the status check.

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

  Conciseness4/5

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

  Three sentences, compact and dense with useful info covering endpoint, async behavior, and auth. Slightly dense syntax ('Async until COMPLETED') but no waste. Could be marginally clearer about the body example.

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

  Completeness3/5

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

  The tool is moderately complex (async status, multiple auth modes, 3 params, no output schema), and the description covers the endpoint, auth, and async nature. However, the third parameter (delete_media_on_completion) is undocumented in both schema and description, and with no output schema or annotation, important behavior like error handling and COMPLETED payload shape is unexplained.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It names queue_id and model in the POST body and explains the purpose of queue_id (identifying queued job), but provides no detail on the body format beyond naming the fields, and doesn't mention delete_media_on_completion parameter at all.

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

  Purpose5/5

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

  The description clearly states the tool checks status of a queued music job via POST /v1/audio/retrieve, distinguishing it from siblings like venice_music_generate (creation) and venice_music_complete. 'Check status' is a specific verb+resource pairing that aligns with the 'Status' title.

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

  Usage Guidelines4/5

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

  The description implies this is for checking already-queued music jobs (async until COMPLETED), giving context on when to use it. However, it doesn't explicitly name alternatives or state when NOT to use it, though the distinction from generate/complete siblings is reasonably clear.

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

• venice_text_parserA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses key behaviors: server-side URL fetching, multipart/form-data upload, and supported formats — all genuine additions. However, it doesn't disclose output format details (does it return plain text? structured JSON?), limits, or failure behavior for unsupported formats, which would be valuable for a parsing tool with no output schema.

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

  Conciseness4/5

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

  The description is compact at about three sentences and leads with the core purpose. Every sentence contributes: extraction purpose, file formats, auth methods, and operator preference. The format-details line could arguably be trimmed, but it's informative. Slightly dense but well-organized and front-loaded.

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

  Completeness3/5

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

  For a single-parameter tool with no output schema and moderate complexity, the description covers the essential input behavior well. However, missing output format expectations and error/failure behaviors for a parsing tool is notable. Given the auth complexity (x402 vs API key) and document parsing nature, a bit more detail on return structure and constraints would improve completeness, but the description is largely adequate.

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

  Parameters4/5

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

  The schema has a single 'url' parameter with 0% description coverage, so the description must compensate. The description does add meaning: it clarifies the URL is fetched server-side and the file is uploaded as multipart/form-data — context that isn't in the schema. However, it doesn't specify URL format requirements beyond the schema's 'uri' format hint, omitting details like whether signed URLs or authorization headers are supported.

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

  Purpose5/5

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

  The description clearly states the tool extracts text from a document URL, explicitly lists supported formats (PDF/DOCX/EPUB/PPTX/XLSX), and includes a specific verb+resource ('Extract text from a document URL'). It distinguishes well from siblings like venice_web_scrape (generic web scraping) and venice_asr (audio transcription) by being explicitly document-focused.

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

  Usage Guidelines3/5

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

  The description states it fetches the URL server-side and specifies an operator preference parameter, providing some context for how it's invoked. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., when one would choose this over venice_web_scrape for PDFs), nor does it provide exclusions or prerequisites. The auth note ('x402 wallet auth') adds useful access context.

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

• venice_chatA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses key behaviors: uncensored nature (NSFW allowed where model permits), auth methods (x402 wallet, API key), context limits (524K, 1M reachable), and model catalog scope. For a chat tool with no annotations, this is substantive disclosure of safety/staleness/auth traits.

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

  Conciseness4/5

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

  Dense but efficient single paragraph. Provides operator preferences as a compact shorthand. Somewhat packed (the 'cheap+long → 1M ctx → character voice → premium reasoning' chain is telegraphic but informative). No wasted words, though it could be structured with clearer separators.

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

  Completeness4/5

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

  For a 6-param no-output-schema tool, the description covers model selection, auth, uncensored policy, and context limits. The main gap is undocumented sampling parameters (stop, top_p, temperature, max_tokens are barely semantic), and no mention of what the response contains. Handles the catalog/scale complexity well.

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

  Parameters3/5

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

  Schema coverage is only 33% (messages and model have descriptions), so the description partially compensates by mentioning model selection guidance. However, it adds nothing about stop, top_p, max_tokens, or temperature beyond what's in the schema (which documents messages and model only). The other 4 params are undocumented in both schema and description, creating a coverage gap.

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

  Purpose4/5

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

  The description clearly states the tool runs an OpenAI-compatible chat completion via Venice's LLM catalog, naming specific models. It's distinct from venice_responses and venice_chat_with_character because it's the raw LLM chat endpoint rather than character-based. Could be slightly better at explicitly contrasting with venice_responses, but the verb+resource+scope is clear.

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

  Usage Guidelines4/5

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

  Provides concrete guidance: default model selection, alternative models to try, context-length escalation ladder (cheap+long -> 1M ctx -> character voice -> premium reasoning), and NSFW allowance. Names alternatives (qwen-3-7-max, venice-uncensored-role-play, gemini-3-1-pro-preview). Doesn't explicitly say when NOT to use it vs venice_chat_with_character or venice_responses, which is a minor gap.

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

• venice_embeddingsA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses auth options ('Supports x402 wallet auth (no Venice account needed) and API key'), which is valuable operational context. It also establishes the OpenAI-compatible interface. It doesn't mention rate limits or output format, but for an embeddings tool the key behavioral aspects (auth, batch preference) are covered.

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

  Conciseness5/5

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

  Three sentences, each earning its place: the core purpose, operator preferences for model selection, and auth requirements. No fluff or redundancy. Extremely efficient.

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

  Completeness4/5

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

  For a tool with 3 params, 67% schema coverage, and no output schema, the description reasonably covers the essentials: purpose, default model, batch preference, and auth. It could mention the return format (embedding vectors) but since no output schema exists, some return-type guidance would strengthen this. Still, it's reasonably complete for a straightforward embeddings API wrapper.

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

  Parameters3/5

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

  Schema coverage is 67% (2 of 3 params get descriptions: input and model are described, encoding_format has an enum listing 'float'/'base64' but no prose). The description mentions text input and the OpenAI-compatible nature, but adds minimal detail beyond schema. The default model mention adds some value for the model param, but encoding_format semantics are only implied by the enum.

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

  Purpose4/5

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

  The description clearly states 'Compute embeddings for text input (OpenAI-compatible)' using a specific verb+resource pairing. It distinguishes itself from sibling tools like venice_chat and venice_responses by specifying the embedding domain. However, it doesn't explicitly differentiate from potential embedding-related siblings, though none appear in the list given.

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

  Usage Guidelines4/5

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

  The description provides useful selection guidance: 'Operator preferences — default: text-embedding-3-small; also try: gemini-embedding-001' and notes 'Operator batch preferred; OpenAI-compatible.' This gives the agent context on which model to choose and batching preference. It doesn't explicitly state when not to use the tool or name alternatives, but the operator-preference guidance is substantive.

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

• venice_image_generateA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosure. It explicitly reveals the NSFW/uncensored capability and auth behavior (x402 wallet, no Venice account needed, API key support), which is significant behavioral context beyond the schema. It stops short of describing output format, failure modes, or rate limits, so not a 5, but it covers the most behaviorally relevant traits.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the core purpose, then fills in model guidance and auth details. All sentences earn their place. Slight redundancy: 'Operator preferences — default: flux-2-pro' and 'Operator default is flux-2-pro' repeat the same information, which is minor waste.

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

  Completeness4/5

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

  For a 9-parameter complex generation tool with no output schema and very low schema coverage, the description provides model selection guidance, default model, uncensored capability, and auth requirements. It's reasonably complete for invocation needs despite not documenting every parameter. Loses a point for not explaining width/height constraints or safe_mode implications, which the text could clarify beyond the schema names.

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

  Parameters3/5

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

  Schema description coverage is only 22%, well below the 80% baseline, so the description needs to compensate. It does add model-choice semantics ('nano-banana-pro for photoreal'), which maps to the model parameter and adds real value. However, the description does not clarify dimensions of remaining parameters like seed, steps, safe_mode, or negative_prompt semantics beyond what schema names suggest. Partial compensation only.

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

  Purpose5/5

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

  The description clearly states the tool 'Generates an image' with a specific verb+resource, enumerates supported models (Flux 2 Pro/Max, Lustify SDXL, Anime, Qwen, GPT Image, Nano Banana Pro), and distinguishes it from siblings like venice_image_edit and venice_image_multi_edit by focusing on generation. It's specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides operator preference guidance with defaults (flux-2-pro) and explicit model selection guidance for use cases: nano-banana-pro for photoreal, anime-wai for stylization, lustify-sdxl for character work. It names the default model, which helps the agent know what to expect. However, it doesn't explicitly contrast with when NOT to use this tool versus venice_image_edit or other sibling image tools, missing some exclusion guidance.

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

• venice_image_upscaleA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses key behaviors: it fetches URLs itself instead of accepting base64 directly, handles alternative auth (x402 wallet, no Venice account needed), returns base64 PNG, and mentions operator preference details (default flux-2-pro, nano-banana-pro). This is rich operational transparency for a tool with zero annotations.

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

  Conciseness4/5

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

  The description is reasonably compact at around 50 words and front-loaded with the core action. The operator preference and auth details are useful additions. Slightly dense with multiple clauses, but each sentence contributes meaningful information without waste.

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

  Completeness4/5

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

  For a 4-param tool with no output schema and only 25% schema coverage, the description is fairly complete: it covers the input handling, output format, scale/effect scope, operator defaults, and auth requirements. Minor gaps: the exact interaction between enhance and replication parameters and what 'replication control' means operationally are not fully specified, but given zero annotations, this is strong coverage.

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

  Parameters3/5

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

  Schema description coverage is only 25% (only image_url and scale have schema descriptions), so the description partially compensates by clarifying scale meaning and image handling. However, it doesn't explain 'enhance' and 'replication' parameter semantics beyond their schema names, leaving their meaning and interaction somewhat ambiguous despite the description mentioning 'enhancement + replication control' in general terms.

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

  Purpose5/5

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

  The description states a specific verb+resource ('Upscale an image') with scale range (1-4×), clearly distinguishing from siblings like venice_image_generate/edit/remove_bg. It also covers the operational mechanism (fetches URL, uploads base64) and output format (base64 PNG).

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

  Usage Guidelines4/5

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

  The description implies context primarily through specifying 'enhancement + replication control' and the scale semantics. It doesn't explicitly say when NOT to use it or name alternatives, but the mechanical detail about URL fetching vs base64 endpoint and auth options (x402 wallet vs API key) provides useful decision context. Lacks explicit exclusions or sibling comparison.

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

• venice_list_modelsA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses that no authentication is needed (a useful behavioral fact) and that it returns capabilities + pricing. However, it doesn't disclose the response format (structured model list vs. prose), pagination/limits, or freshness of the catalog data.

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

  Conciseness4/5

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

  Three concise sentences, all carrying useful information: live catalog, capabilities+prices, and authentication status. Zero waste. Slightly repetitive between sentence one and two ('List the live model catalog' / 'Live catalog'), but otherwise tight.

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

  Completeness4/5

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

  For a read-only listing tool with one optional filter parameter and no output schema, the description covers the essential purpose, the key output contents (capabilities + prices), and authentication requirements. It's adequate but could note whether results differ by filter type or whether pricing is current/rate-limited.

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

  Parameters4/5

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

  The single parameter 'type' has a full enum (text, image, video, audio, etc.) in the schema, so the schema does most of the work. The description adds context that the catalog includes capability flags and pricing per model, which hints the filter parameter is about model category. With 0% schema description coverage, the description partially compensates by clarifying the overall meaning of catalog contents.

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

  Purpose5/5

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

  States a specific verb+resource ('List the live model catalog') and adds scope details: capabilities, prices, USD pricing, no authentication needed. This clearly differentiates it from sibling generation/completion tools like venice_chat or venice_image_generate.

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

  Usage Guidelines4/5

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

  The description implies discovery/exploration use (listing a catalog), which is implicitly distinct from siblings that perform actions. It notes 'No authentication required', which signals accessibility. However, it doesn't explicitly state when NOT to use it or mention alternatives for other needs.

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

• venice_image_stylesA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden. It discloses that no authentication is required, which is useful. However, it doesn't disclose the output format (list of preset names/IDs, with descriptions?) or whether results are ordered/categorized, though for a simple list tool this is a modest gap.

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

  Conciseness5/5

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

  Two sentences, zero wasted words. The first sentence states the core purpose with target reference, the second handles the auth detail. Perfectly front-loaded and efficient.

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

  Completeness4/5

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

  For a zero-parameter list tool with a clear sibling relationship and no output schema, this is reasonably complete. It tells the agent what it lists, who it serves, and the auth requirement. Could mention what the return format looks like, but for a simple preset-listing tool this is adequate.

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

  Parameters4/5

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

  The tool has 0 parameters, and schema description coverage is 100%. With no parameters to document, the description has nothing to add to the schema. A 4 is appropriate since the tool's parameter surface is empty, so the description's job of explaining parameters is trivially satisfied.

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

  Purpose5/5

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

  The description clearly states the tool lists image style presets for venice_image_generate. The verb 'List' is specific, the resource (image style presets) is clear, and it establishes the relationship with its sibling tool venice_image_generate, which distinguishes its purpose well.

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

  Usage Guidelines4/5

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

  The description implies this is a companion/setup tool for venice_image_generate by naming that tool explicitly. It establishes clear context for when to use it, though it doesn't explicitly state when NOT to use it or name exclusion scenarios. The 'No authentication required' note provides a useful accessibility cue.

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

• venice_x402_balanceA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses that API key auth is rejected, that the SIWX token must be forwarded, and crucially that the wallet in the path must match the SIWX-authenticated wallet — a key constraint that would cause failures if unknown. This is meaningful behavioral context beyond the parameter schema.

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

  Conciseness4/5

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

  Two concise sentences that are front-loaded with the core purpose, followed by the critical auth constraint. Minimal waste, though the SIWX detail could be slightly condensed. Efficient overall.

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

  Completeness4/5

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

  For a single-parameter, no-output-schema tool, the description covers the essential points: what it does, the auth requirement, and the critical wallet-matching constraint. It doesn't describe the response format, but with no output schema and a simple balance check, this is a reasonable gap. Slightly more on what the returned balance represents could help, but it's largely complete.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. The description explains the wallet_address parameter's role (must match the SIWX-authenticated wallet) which adds semantic constraint beyond the hex pattern in the schema. The wallet format is already enforced by the schema pattern, so the description's added value is the matching constraint.

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

  Purpose5/5

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

  The description clearly states the tool checks the 'prepaid x402 credit balance for a wallet address' — a specific verb (check), resource (prepaid x402 credit balance), and target (wallet address). It also distinguishes from siblings like venice_x402_transactions and venice_x402_top_up_info by focusing on balance checking.

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

  Usage Guidelines4/5

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

  The description explicitly states when not to use it: 'SIWX-ONLY: this endpoint rejects API key auth and requires X-Sign-In-With-X (forwarded from VENICE_SIWX_TOKEN).' This is clear context about authentication prerequisites. It doesn't explicitly name alternative tools, but the auth constraint is the primary usage gate, which is well communicated.

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

• venice_x402_top_up_infoA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It explicitly notes that steps 2-3 occur outside the server, clarifying the tool's limited scope. However, it doesn't disclose what happens if the wallet_address is invalid or whether the requirements vary by wallet — a minor gap, but the main behavioral trait (it's a read-only requirements fetch) is clear from the 'fetch' framing.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the purpose, and zero wasted words. The parenthetical note about steps 2-3 is efficiently packed into one clause without redundancy.

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

  Completeness4/5

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

  The tool has no output schema, so the description's enum of fetched fields (network, USDC token address, receiver wallet, min amount) partially compensates by telling the agent what to expect in the return. But the tool is part of a multi-step x402 flow and lacks any context about authentication, rate limits, or the relationship between x402 top-up and the sibling x402 balance/transactions tools. It's adequate but not fully complete for a multi-step financial flow.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain both parameters. It explains nothing about 'amount_usd' (optional) or 'wallet_address' semantics beyond what the schema pattern shows. The description names the output fields but doesn't clarify how wallet_address relates to the returned requirements or whether amount_usd affects the response. With 0% coverage and 2 parameters, this is a significant gap.

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

  Purpose5/5

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

  The description clearly states the tool fetches step-1 top-up requirements specifying exactly what fields it provides (network, USDC token address, receiver wallet, min amount). The verb 'fetch' is specific, the resource is clearly named, and it effectively distinguishes itself from the sibling x402 tools (balance, transactions) which serve different purposes.

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

  Usage Guidelines5/5

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

  The description explicitly explains that steps 2 and 3 require a wallet and happen outside this MCP server, clearly scoping when this tool is appropriate. This is an explicit when/when-not framing that prevents the agent from attempting to complete the full top-up flow through this tool.

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

• venice_x402_transactionsA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full behavioral disclosure burden. It discloses the auth requirement (SIWX-only, rejects API key) and the wallet-matching constraint, which are critical behavioral traits. It doesn't detail pagination, ordering semantics, or return format traits, but for a read-only list operation the disclosed constraints are substantial and useful.

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

  Conciseness5/5

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

  Three compact sentences, all earning their place: purpose, auth constraint, and wallet-matching rule. No filler, no repetition of schema content. Front-loaded with the core action.

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

  Completeness4/5

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

  For an auth-gated list tool with no output schema, the description covers the essential behavioral details: verb, resource, auth requirement, and wallet validation constraint. It's slightly incomplete not describing pagination/ordering for 'recent' transactions, but it's adequate given the tool's relative simplicity.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description must compensate. The description names the key parameter concept (wallet in path must match SIWX-authenticated wallet) but doesn't document the `limit` parameter's semantics or format. It adds some value by clarifying the wallet constraint, but `limit` is left undocumented at the semantic level.

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

  Purpose5/5

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

  Description clearly states the verb (list), the resource (x402 top-up + debit transactions), and the scope (for a wallet, recent). It distinguishes itself well from sibling tools like venice_x402_balance (balance) and venice_x402_top_up_info (top-up info), so the purpose is specific and differentiated.

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

  Usage Guidelines5/5

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

  Explicitly states auth requirement (X-Sign-In-With-X / VENICE_SIWX_TOKEN), explicitly excludes API key auth, and states the path-wallet-must-match-authenticated-wallet constraint. This gives clear when-to-use and preconditions. It implicitly distinguishes from other venice tools by its exclusive SIWX auth model, which is a strong usage signal.

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

• venice_video_generateA
  4.6/5.0
  Behavior4/5

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

  No annotations exist, so description carries full burden. It discloses auth mechanisms (x402 wallet, API key), NSFW permissiveness, return format ({model, queue_id}), and duration being an enum. Slightly less transparent about failure modes, rate limits, or what happens on queue rejection, but the disclosures present are strong.

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

  Conciseness4/5

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

  Rich with information but somewhat dense and run-on in style; multiple concepts packed into a few sentences requiring careful parsing. Still, every sentence adds value—model selection, operator prefs, auth, NSFW, return/polling, and duration caveat all earn their place. Slightly front-loads the most critical info (queuing + models).

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

  Completeness5/5

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

  Highly complete for an 18-parameter tool. The schema already documents most parameters well (83% coverage), and the description compensates for the gap by explaining duration enum semantics, operator model preferences, quoting flow, wallet auth, and NSFW policy. Return value and polling flow clearly conveyed. No output schema, but description handles expectations adequately.

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

  Parameters4/5

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

  Schema coverage is high at 83%, so baseline is 3. The description adds value beyond schema by explaining duration as a string enum, clarifying operator-preferred model ids, and noting that elements/scene images use @Element/@Image referencing. The model parameter receives substantial contextual enrichment not in the schema.

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

  Purpose5/5

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

  Clearly states it queues a video generation and lists specific supported models with concrete id examples. Distinguishes from sibling tools like venice_image_generate, venice_music_generate, and venice_video_complete by focusing on the queueing action and mentioning polling via venice_video_status.

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

  Usage Guidelines5/5

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

  Provides explicit operator preferences with default (ltx-2 for speed), premium tiers (sora-2/veo3.1/kling), and task-specific guidance (seedance for video-to-video). States when to quote (always via venice_video_quote) and polling expectation. Mentions auth options and NSFW policy. This is exceptional usage guidance.

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