Server Quality Checklist

Tool Scores

• from_filesC
  2.3/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 of behavioral disclosure. It does not mention that this performs a read-only vision operation, that Gemini is the underlying model, whether it needs connectivity/auth, how it handles the 'compact' parameter (which affects history), or what the output looks like. The word 'describe' implies read-only but nothing is explicitly disclosed.

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

  Conciseness3/5

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

  The description is a single short sentence, which is appropriately brief for an alias tool. However, it is so short it borders on under-specification — it fronts the alias relationship but contains zero substantive standalone guidance. It's concise, but conciseness without content is closer to under-specification than efficiency.

  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?

  Despite having an output schema and 100% param coverage, the tool needs more because it operates in a crowded sibling family (from_files, from_resources, multiple _mixed variants). The description does not explain how this alias differs from using vision_from_files directly, and there is an unused 'compact' parameter whose behavioral effect is entirely unexplained. For a tool with many similar siblings, this is incomplete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 4 parameters (type, paths, prompt, compact). The description adds no parameter meaning beyond the schema. Per calibration, baseline is 3 when schema covers params fully, and the description provides no incremental value here.

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

  Purpose2/5

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

  The description is almost entirely a tautology — it simply states 'Alias for vision_from_files — describe multiple files using Gemini.' It does state the purpose (describe multiple files) but only by referencing a sibling tool. It adds no independent verb+resource clarity of its own and relies entirely on the reader knowing what vision_from_files does. The purpose is technically present but thin and derivative.

  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 names vision_from_files as the canonical tool, implying this is an alias, but it gives no guidance on when to use this alias vs the direct tool or the many sibling variants (from_file, from_files_mixed, from_resources, etc.). No context about when this is preferred, what makes it an alias worth using, or when NOT to use it.

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

• from_resourcesC
  2.4/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. As an alias it discloses that it uses Gemini, but it does not describe what happens to the resources (are they all sent simultaneously? Is there a size limit? Does compact affect behavior?). The description mentions 'describe multiple URLs' but gives no behavioral detail beyond the schema already provides.

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

  Conciseness4/5

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

  The description is a single efficient sentence. It's front-loaded with the essential purpose. However, as an alias it's arguably too sparse given the complex sibling landscape, but for pure conciseness it scores well — no wasted words.

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

  Completeness2/5

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

  The tool has 4 parameters, an output schema, and lives among 13 siblings including near-identical naming patterns (from_file, from_files, from_resources, from_resources_mixed). An alias description that merely references another tool is inadequate for an agent to confidently select this one. There's no guidance on what distinguishes this alias from the canonical tool or from variants like from_resources_mixed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all 4 parameters (type, prompt, compact, resources). The description adds minimal value — it confirms 'multiple URLs' maps to the resources array, but this is already stated in the schema. With full coverage, baseline 3 is appropriate.

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

  Purpose2/5

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

  The description says it's an 'Alias for vision_from_resources — describe multiple URLs using Gemini.' It identifies the tool as describing multiple URLs, but as an alias it does not stand on its own as a purpose statement — it merely points to another tool. The verb 'describe' and resource type (URLs) is specified, but the primary function is delegated to a different tool name, which weakens self-contained clarity.

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

  Usage Guidelines2/5

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

  No guidance on when to use this alias vs. the canonical vision_from_resources or when to choose from_resources over from_files/from_resource. With a crowded sibling set (from_resources, from_resource, from_files, from_resources_mixed, etc.), the description offers no differentiation. It simply asserts it's an alias without adding when-to-use context.

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

• vision_from_filesC
  2.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 of behavioral disclosure. It does not disclose what 'one Gemini session' means operationally, whether multiple file types are accepted (the 'mixed' siblings suggest this tool only handles one type), what happens on errors, or the cost/usage implications of a session. The 'compact' parameter hints at session lifecycle but the description never mentions session management.

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

  Conciseness3/5

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

  The description is a single short sentence, which is economical and front-loaded. However, it is under-specified — it lacks key context that would make the tool usable, which is not a conciseness virtue but rather incomplete specification. It earns a middle score for brevity but loses points for missing substance.

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

  Completeness2/5

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

  There is an output schema, so return values are covered elsewhere. However, given the complexity of a multi-file session tool with 4 parameters (including one enum) and nearly a dozen siblings, the description is too thin. It does not explain session semantics, type restrictions per session, or how it differs from the 'mixed' variants. A tool this complex needs more behavioral and usage context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter has its own description in the schema. The description adds minimal value beyond that — 'Describe multiple files' loosely maps to the paths+type+prompt parameters but adds no semantic depth. Baseline 3 is appropriate given full schema coverage.

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

  Purpose3/5

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

  The description 'Describe multiple files in one Gemini session' uses a verb (describe) and resource (multiple files), but is quite terse. It doesn't distinguish itself from siblings like vision_from_files_mixed, from_files, or from_files_mixed, all of which appear to process multiple files. The phrase 'one Gemini session' hints at batch processing but doesn't explain how it differs from the plural siblings.

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

  Usage Guidelines2/5

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

  No when-to-use or when-not-to-use guidance is provided. With seven sibling tools that appear to handle files/resources (vision_from_file, from_files, from_files_mixed, vision_from_resource, from_resources, etc.), there is no guidance on when to pick this tool over alternatives. The 'one session' wording is the only hint but lacks explanation.

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

• from_fileC
  2.6/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 full burden for behavioral disclosure. It states that the tool describes a single file using Gemini, but provides no detail on what happens — whether it reads local files only (implied by 'path' but not stated), behavior of the 'compact' parameter, error handling, file size limits, or whether multiple files are rejected. There is no mention of the alias relationship's behavior implications. The description is too thin to convey meaningful behavioral transparency.

  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 one sentence and extremely efficient: 'Alias for vision_from_file — describe a single file using Gemini.' There is zero waste. However, it is under-specified rather than concisely complete — brevity here trades off against missing critical guidance about when to use this vs alternatives. It earns a 4 for being tight, but this is brevity bordering on underspecification.

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

  Completeness2/5

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

  The tool has 4 parameters (3 required), an output schema, and 14 highly-similar sibling tools. The description does not address the most important contextual question: how does this alias differ from its target vision_from_file, and when should an agent choose one over the other? The output schema exists so return values need not be explained, but the selection criteria among the dense sibling set is entirely absent. For a tool with this many near-identical siblings, the description is materially incomplete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 4 parameters (path, type, prompt, compact) are documented in the schema itself. Per the rubric, baseline is 3 when schema coverage is high. The description adds no parameter-specific information beyond what the schema already provides — the 'single file' nuance is the only marginal addition. No extra format, validation, or interaction guidance is given.

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

  Purpose3/5

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

  The description states it is an 'Alias for vision_from_file — describe a single file using Gemini.' This clearly identifies the verb (describe), resource (single file), and scope (using Gemini). However, it doesn't add meaningful purpose beyond what the tool name and sibling name suggest — it's essentially a pointer to another tool rather than a standalone description. It distinguishes from 'from_files' (plural) but mostly through the alias reference.

  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 only says it's an alias for vision_from_file. It doesn't state when to use this tool vs the sibling vision_from_file or when to use from_file(s) vs the vision_* variants. No exclusions or contextual guidance are provided. The sheer number of closely-related sibling tools (from_files, from_resources, from_files_mixed, from_resources_mixed) makes the lack of differentiation particularly problematic — an agent could not distinguish correct usage from the description alone.

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

• vision_from_resourceC
  2.6/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 of behavioral disclosure. It states the tool 'describes' a resource via Gemini but does not disclose what happens with the resource (fetching, media decoding errors, size limits), whether a prompt modifies behavior, what the return format looks like (though an output schema exists), or how the 'compact' parameter affects behavior (reconnect semantics are unexplained). The description is a bare statement of function without behavioral detail.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no wasted words. It front-loads the primary function clearly. However, given the richness of the tool (four parameters, media types, output schema), the extreme brevity borders on under-specification rather than conciseness.

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

  Completeness2/5

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

  The tool has an output schema and full parameter coverage, which helps. However, with no annotations and a complex sibling landscape (11 related tools varying by input source and plurality), the description should do more to clarify when the single-URL vision variant is appropriate. The bare 'Describe a URL resource using Gemini' does not cover media-type handling, error behavior, or distinction from non-vision from_resource sibling.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all four parameters already have descriptions. The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate. One minor note: the 'compact' parameter's reconnect behavior is opaque even in the schema, and the description does not clarify it, but with full coverage the schema carries the burden.

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

  Purpose3/5

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

  The description 'Describe a URL resource using Gemini' is concise and identifies the core action (describe a resource via URL) and underlying model (Gemini). However, it does not differentiate from siblings like vision_from_file (file vs resource distinction exists in the schema parameter names, but not elaborated in the description) or vision_from_resources (plural variant). The purpose is clear but the scope and distinction from sibling tools is under-specified.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. Siblings include from_resource, from_resources, vision_from_resources, and vision_from_file, which differ in input source (single vs multiple, URL vs file) and whether vision (Gemini multimodal) is used. No exclusions or contextual guidance are given, leaving the agent to infer when the URL-resource form is appropriate.

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

• vision_from_resourcesC
  2.6/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 full burden. It reveals this fetches multiple URLs in a single 'Gemini session,' which hints at batching behavior. But it doesn't disclose what happens on mixed media types, rate limits, size constraints, or failure behavior for individual URLs. Given zero annotation coverage, this is a notable gap for a tool that fetches external resources.

  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 single-sentence description is efficient with no wasted words, but it's under-specified. It echoes what the name already conveys ('vision_from_resources') with little additional elaboration on the session behavior beyond the one gem. Short is good, but this crosses from concise to thin.

  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 an output schema present and 100% parameter coverage, much of the needed structure is in place. However, with many sibling tools (from_file, from_files, mixed variants, new_vision), the description doesn't explain the distinguishing session model or the mixed-media advantage. Given the complexity of this tool family, more context on when this specific one applies would help.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 4 parameters are documented in the schema itself (type as enum, prompt as instructions, compact, resources as URL list). The description adds minimal value beyond the schema — it only signals session batching. Baseline 3 is appropriate since the schema carries the semantic weight.

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

  Purpose3/5

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

  The description says 'Describe multiple URL resources in one Gemini session,' which states a verb+resource (describe multiple URL resources) and distinguishes from vision_from_file (single file) and vision_from_resource (single resource) via the plural 'resources.' However, it's terse and doesn't fully capture what 'describe' means — extract, summarize, analyze? Though the name and plural form differentiate from siblings, the verb 'describe' is somewhat generic.

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

  Usage Guidelines2/5

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

  No when-to-use guidance is provided. The plural 'resources' implies it's for multiple URLs vs. vision_from_resource for a single one, but this is only implicit in the name, not stated in the description. No exclusions, alternatives, or context about when this tool is the right choice versus vision_from_files_mixed or vision_from_resources_mixed.

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

• from_files_mixedC
  2.7/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 of behavioral disclosure. It mentions 'describe mixed-type files using Gemini' which reveals the model being used, but doesn't explain limitations, error behavior, whether files must exist locally, or output characteristics beyond what the output schema reflects. Being an alias for another tool, it would have been useful to note the canonical tool name.

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

  Conciseness4/5

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

  The description is a single concise sentence. It's efficient with no wasted words. However, it's arguably under-specified rather than genuinely concise — the brevity comes from deferring all substance to the alias target.

  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 an output schema present and complete parameter schema coverage, the basic contract is documented. However, for a tool that's defined purely as an alias among 15 similar sibling tools, the description fails to explain the relationship to siblings (especially its canonical twin vision_from_files_mixed and the non-vision from_files_mixed). This is a moderate gap given the tool's 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 description coverage is 100%, so all four parameters (paths, types, prompt, compact) are documented in the schema itself. The description adds no additional parameter meaning beyond that. The constraint that paths must match types length is noted in the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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

  Purpose3/5

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

  The description identifies this as an alias for vision_from_files_mixed and states it describes mixed-type files using Gemini. The purpose is understandable but relies entirely on referencing the sibling tool rather than stating its own distinct function; given the many sibling tools (from_file, from_files, vision_from_files, etc.), the description does little to distinguish this alias's behavior from alternatives.

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

  Usage Guidelines2/5

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

  No when-to-use or when-not-to-use guidance is provided. The description doesn't explain when to prefer this alias over vision_from_files_mixed itself, or how this tool differs from from_files_mixed (non-vision) or vision_from_files (single-type). Naming it an 'alias' implies equivalence but gives no usage context.

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

• from_resources_mixedC
  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 of behavioral disclosure. It reveals that the tool is an alias and uses Gemini, but discloses nothing about side effects, whether it's read-only, API key requirements, cost implications of using Gemini, or behavior with mixed-type sources. The description partially addresses the mixed-type behavioral aspect but otherwise leaves the safety and side-effect profile undocumented. Since no annotation contradiction exists, this is not a score-1 case, but for a tool with zero annotation coverage the disclosure is thin.

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

  Conciseness4/5

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

  The description is a single concise sentence that front-loads the key information (alias relationship and primary purpose). It's efficient and avoids wasteful prose. The one-line format is appropriate for what is essentially an alias wrapper, though a bit more behavioral context could have been added without harming conciseness.

  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?

  Despite having an output schema, no annotations, and a large sibling family of 14 tools, the description does very little contextual work. It identifies the canonical tool but doesn't explain the mixed-type semantics vs singular-type siblings, when to use resources over files, or the Gemini model implications. For an alias in a complex and confusing sibling namespace, more disambiguation guidance is warranted to help the agent select correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 4 parameters (types, prompt, compact, resources) are documented in the schema itself, establishing a baseline of 3. The description adds minimal value beyond the schema — it doesn't clarify the types-resources length correspondence beyond what the schema notes ('must match length of types'), nor does it explain the compact flag's behavior. It does reinforce the 'mixed' concept, but this is largely redundant with the schema.

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

  Purpose3/5

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

  The description states this is an alias for vision_from_resources_mixed and that it describes mixed-type URLs using Gemini. The verb 'describe' and resource 'mixed-type URLs' give the purpose, and it correctly identifies the underlying primary tool. However, it doesn't explain what makes this tool distinct from its many sibling aliases (from_resources_mixed, vision_from_resources, from_resources, etc.), relying on the alias reference for differentiation.

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

  Usage Guidelines3/5

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

  The description implies the usage context by identifying the canonical tool (vision_from_resources_mixed), which lets an agent infer that the vision variants handle multimedia description while non-vision ones may not. However, among the large sibling family (from_resource, from_resources, from_file, from_files, mixed variants, etc.), there's no explicit guidance on when to pick this over from_resources (singular type) or from_files_mixed (files vs resources). The singular vs plural resource distinction is only implied, not stated.

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

• from_resourceC
  2.9/5.0
  Behavior2/5

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

  No annotations provided, so the description carries full responsibility. It discloses that this is a vision (Gemini) operation on a URL, implicitly indicating it is read-only in nature. However, it doesn't mention behavior around the compact parameter (history compaction/reconnection — a notable side effect), error handling for malformed URLs or unsupported media types, rate limits, or what happens on unsupported resource types, despite the output schema existing.

  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?

  Extremely concise — a single sentence that defers to the canonical tool. Front-loaded and efficient with zero wasted words. Given that it's an alias, brevity is appropriate. Loses a point because it relies entirely on the alias target; for a self-contained description it is too minimal.

  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?

  As an alias for a tool with 4 parameters (3 required), an output schema, a media type enum, and many sibling variants (plural vs singular, vision vs non-vision), the description is too sparse. It names only vision_from_resource while the plural and file-based siblings exist. While the output schema mitigates return-value explanation needs, the description does not explain how this differs from vision_from_file, from_resource, or the plural variants.

  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%, with all four parameters documented in the schema itself, so baseline is 3. The description itself adds no parameter detail beyond pointing to vision_from_resource. The compact parameter's behavior (compacting history, reconnecting) is documented only in schema, not description. Adequate given the alias's extreme brevity.

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

  Purpose4/5

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

  The description clearly identifies it as an alias for vision_from_resource and states it describes a URL using Gemini. Purpose is clear (verb 'describe' + resource 'URL' + tool 'Gemini'), though it doesn't distinguish from the vision_from_resources plural sibling or the from_resource non-vision variant, instead deferring entirely to the aliased tool.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this alias versus vision_from_resource, vision_from_resources, or from_resource. The 'alias for' framing implies users should normally call the canonical tool, but there's no exclusions, no alternatives named beyond the single alias target, and no context about when this vs siblings is preferable. For an agent with many sibling tools, this is a gap.

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

• vision_from_fileC
  2.9/5.0
  Behavior2/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 behavioral disclosure. It doesn't mention that this invokes a Gemini model call (with associated cost/latency), doesn't explain what the returned output looks like, doesn't disclose any failure modes (e.g., unsupported file formats, large-file limits), and doesn't mention the compact parameter's effect of history compaction. The behavior of using an external AI model is a non-trivial side effect that should be disclosed.

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

  Conciseness5/5

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

  The description is a single concise sentence: 'Describe a single file (image, audio, video, or text) using Gemini.' It front-loads the core purpose with no wasted words and no redundant repetition of the schema fields. Highly efficient.

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

  Completeness2/5

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

  The description omits key context: that Gemini is an external AI service with potential cost/latency implications, that different file types (audio/video) have different processing requirements, and any guidance on how to craft the prompt parameter. It does have an output schema, which lessens the need to explain return values, but for an AI-invoking tool with multiple media types, more completeness is expected.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all four parameters (path, type, prompt, compact) are documented in the schema. The description adds the media-category context (image, audio, video, or text) which maps to the type enum, but doesn't add detail about any parameter beyond what the schema already provides. At 100% coverage the baseline of 3 applies, and the description adds minimal additional semantics.

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

  Purpose4/5

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

  The description 'Describe a single file (image, audio, video, or text) using Gemini' uses a clear verb (describe) with a specific resource (single file) and media categories. The 'single' qualifier distinguishes it from plural sibling tools like vision_from_files, from_files, and vision_from_resources. However, it doesn't explicitly differentiate from vision_from_resource, which also does single-resource description.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool vs. siblings. The description doesn't mention when to prefer vision_from_file over vision_from_resource, from_file, vision_from_files, or vision_from_files_mixed. No exclusions or alternative recommendations are given, which is a significant gap given the large sibling set with overlapping purposes.

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

• vision_from_resources_mixedA
  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 behavioral burden. It discloses that resources are compared in 'one Gemini session', which reveals a key behavioral trait (shared session context). However, it doesn't disclose constraints like URL accessibility requirements, rate limits, or what happens on mixed-type failures. The 'one Gemini session' detail provides modest value but is incompletely developed.

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

  Conciseness4/5

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

  The description is a single efficient sentence that captures verb, scope, and mixed-type nature without waste. It's front-loaded with the core action. It could arguably add a bit more differentiation context, but as-is it's appropriately sized for its content.

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

  Completeness3/5

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

  An output schema exists, removing the need to document return values. With 100% schema coverage and a clear description, the tool is reasonably specified. However, for a multi-resource tool with mixed types (text/image/audio/video), there's no guidance on resource count limits, size constraints, or whether separate prompts-per-type are needed. Given the complexity of mixed-type processing, some additional context would strengthen completeness.

  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 100%, so the input schema already documents all parameters, including the types-accepted list and the length-matching requirement between types and resources. The description adds the conceptual framing of 'mixed types' and 'one Gemini session', which enriches understanding of the types and resources semantics beyond the raw schema. This meets the high-coverage baseline and adds some value.

  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 'Describe multiple URL resources of mixed types in one Gemini session' clearly states the verb (describe), resource (multiple URL resources), and scoping ('mixed types', 'in one Gemini session'). It distinguishes from singletons like vision_from_resource and from non-mixed variants like vision_from_resources. However, it doesn't explicitly name the distinguishing sibling, which keeps it from 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?

  The description implies use when handling multiple URL resources of mixed types, which differentiates from same-type variants and singletons. However, there's no explicit 'when to use this vs alternatives' guidance, no exclusions, and no mention of constraints like URL accessibility. It relies on the reader to infer usage from sibling names.

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

• vision_from_files_mixedA
  3.6/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. 'One Gemini session' hints at session-resource management, but doesn't describe side effects like history consumption, limits on file count, session state, or resource cleanup. It doesn't mention the 'compact' behavior or when reconnection occurs. Adequate but minimal.

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

  Conciseness5/5

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

  A single, concise sentence that captures the core function. Zero waste, front-loaded with the primary purpose. Appropriate length for a tool whose parameters are fully documented in the schema.

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

  Completeness4/5

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

  Given 100% schema coverage, a clear single-sentence purpose, and an output schema, the tool has baseline completeness. The presence of sibling 'mixed' variants (vision_from_files_mixed, from_resources_mixed, vision_from_resources_mixed) suggests a family of similar tools, but the description's differentiation is adequate for practical selection. Could add one detail on session implications but is largely sufficient.

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

  Parameters3/5

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

  Schema coverage is 100%, with all params described (paths, types, prompt, compact). The description adds marginal value beyond the schema—it frames the tool's purpose but doesn't deeply explain relationships between types and paths arrays beyond the schema's own 'must match length' note. The compact param is schema-documented but not explained in the 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?

  The description 'Describe multiple files of mixed types in one Gemini session' clearly states the verb (describe), resource (multiple files of mixed types), and context (one Gemini session). It distinguishes from siblings like vision_from_file (single file) and vision_from_resource (resource vs file). However, it doesn't explicitly differentiate from vision_from_files, which appears to be a closely related sibling with similar multiple-file handling.

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

  Usage Guidelines3/5

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

  The description implies usage for mixed-type file batches but provides no explicit when-to-use versus alternatives. Siblings vision_from_files (multiple files) and vision_from_file (single file) suggest related tools, but no guidance is given on when to choose 'mixed' version over the straightforward 'files' version, nor how this relates to from_files_mixed or from_resources_mixed.

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

• gemini_usageA
  3.7/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 states it returns token usage stats and rate limit status, which discloses output behavior. However, it doesn't specify whether this is a read-only operation (likely implied), whether it consumes quota, or what the exact response structure is. The described return content is somewhat disclosed but not fully.

  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 brief sentences, zero filler, front-loaded with the primary purpose. Every word earns its place. This is appropriately concise for a zero-parameter utility tool.

  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 0 parameters and a rich output schema (present), so the description doesn't need to explain return format in detail. For a simple read-only stats tool, the description covers purpose and general return content adequately. Slightly more could be said about rate limit semantics, but it's not critical.

  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?

  There are 0 parameters, so schema description coverage is trivially 100%. The description adds value by explaining what the tool returns (token usage and rate limit status), which is meaningful even with no parameters. For a no-param tool, there's nothing more params could require, so this is well-served.

  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 retrieves Gemini API usage statistics including token usage and rate limit status. The verb 'get' plus resource 'current Gemini API usage statistics' is specific. It's distinct from sibling tools which are all vision/file/message-related, so no confusion with siblings is likely, though it doesn't explicitly name them.

  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 its usage context (checking API usage/rate limits) but provides no explicit when-to-use vs alternatives guidance. However, given the sibling tools are all content/file generation tools, the purpose differentiation is reasonably obvious, so it's acceptable but not explicitly stated.

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

• compactA
  3.9/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 reveals key behaviors: older turns are summarized, recent turns kept verbatim, and content is replayed into a fresh Gemini Live session. However, it doesn't disclose side effects—like whether the original session is destroyed, whether there's a lossy summary tradeoff, identity/auth implications, or rate limits. The core behavior is described but deeper consequences are not.

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

  Conciseness5/5

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

  The description is compact and front-loaded. The first sentence states the purpose immediately. The subsequent sentences add behavioral detail and usage guidance in just a few lines with zero wasted words. Every sentence earns its place.

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

  Completeness4/5

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

  Given this is a zero-parameter tool with an output schema, the description covers the key behavioral aspects: what happens to old turns, what happens to recent turns, and how context is preserved. The only gap is return-value semantics that the output schema presumably covers. For a tool of this complexity, the description is largely complete. A clear 'when not to use' or reference to the output schema would nudge it to 5.

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

  Parameters4/5

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

  With 0 parameters and a 100% schema description coverage, the parameter baseline is 4. There are no parameters to document, which is itself a meaningful signal the tool takes no input. The description appropriately focuses on the tool's behavior rather than parameters, making this dimension inherently satisfied.

  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: 'Compact conversation history and reconnect.' It explains the behavior (summarizes older turns, keeps recent verbatim, replays into a fresh session). It also distinguishes from new_vision by noting context preservation. However, it doesn't explicitly differentiate from the other sibling compact-like tools, though its unique verb/behavior 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?

  The description explicitly says 'Use instead of new_vision when you want to preserve context,' which directly addresses when to use this tool versus an alternative. It states clear context (when context preservation matters) but doesn't cover exclusions or when NOT to use it. Still, naming the specific alternative is strong guidance.

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

• new_visionA
  3.9/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 does disclose the critical behavioral consequence—'Existing conversation history is lost'—which is important and valuable. However, it doesn't disclose what happens to the current state, whether this affects sibling tools, rate limits, or auth requirements. It covers the most critical destructive impact but omits other behavioral details.

  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 short sentences, zero waste. First line states purpose, second gives the trigger condition, third flags the destructive consequence. Every sentence earns its place; effectively front-loaded.

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

  Completeness4/5

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

  For a zero-parameter tool with an output schema present, the description covers the essential aspects: what it does, when to call it, and the key side effect (history loss). Given low complexity, it's adequately complete. The output schema presumably covers the return value, so no need to explain that here.

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

  Parameters4/5

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

  The tool has zero parameters (schema coverage 100% baseline for no-param tools). The description doesn't need to explain parameters since there are none. The baseline 4 for no-param tools applies here, and the description appropriately remains silent on parameters.

  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: 'Force a fresh Gemini Live session' and explains why you'd call it (reset stale/erroring connection). It distinguishes somewhat from siblings, which are all file/resource-based container operations, by being the session-reset tool. Purpose is reasonably specific.

  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 clear context on when to use it: 'Call this to reset the connection if it's stale or returns errors.' It doesn't explicitly name alternatives or exclusions, but the when-to-use guidance is concrete and actionable, distinguishing it from the file/resource container tools among siblings.

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