Server Quality Checklist

Tool Scores

• image_searchA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds meaningful behavior: files are never downloaded or embedded, only links and metadata are returned, and each call costs 1 credit. It also warns about the context cost of a full default result (tens of kilobytes). This goes beyond the annotations without contradicting them.

  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 well-structured with clear sections (When/When not, Returns, Cost) and is front-loaded with the key purpose. However, it is fully repeated in two languages, which doubles length without adding new information. Still, every sentence earns its place in terms of utility.

  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?

  For a search tool with four parameters and no output schema, the description covers the essentials: what is returned, when to use it, cost, and practical num recommendations. It also provides context about response size, which is enough for an agent to select and invoke the tool 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% and already includes detailed guidance (e.g., num default 12, suggestion to use 1–3 for a single image). The description repeats this guidance and adds the context-cost warning, but most parameter meaning is already present in the schema, so the added value is limited.

  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 opens with a specific verb and resource: 'Ищет изображения по текстовому запросу' (searches for images by text query) and clearly lists return values (direct file links, source page, resolution). It also differentiates from sibling tools like web_search and fetch_page by explicitly stating what it does not do.

  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 states when to use the tool ('need pictures, photos, logos or diagrams') and when not to ('need text or facts — web_search; need to see what a specific page looks like — fetch_page'). This directly names alternatives and provides clear context for selection.

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

• deep_researchA
  4.6/5.0
  Behavior5/5

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

  Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds substantial behavioral detail: time range (10s–2min), cost model, non-idempotence (repeating a topic produces a new result and is billed again), and the caveat that missing sources means the output is unverified. No contradiction with 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 well-organized with clear sections (When, Returns, Time, Cost) and front-loaded with the core purpose. However, the content is duplicated in Russian and English, which lengthens it without adding new information, so it barely misses a 5.

  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?

  For a single-parameter tool with no output schema, the description fully covers behavior, return format, failure mode, time expectations, and cost. Nothing essential is missing for an agent to select and invoke this tool 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?

  The input schema already covers the sole parameter 'query' at 100% with a clear description. The tool description adds little beyond calling it a question/research topic, so the baseline of 3 for high schema coverage is appropriate.

  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 'runs multi-step research, forms its own queries, searches, reads sources and returns a finished answer with links' – a specific verb+resource that distinguishes it from siblings, especially naming web_search as the alternative for simpler needs.

  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 'Use when' and 'Do not use when' guidance, naming web_search as the cheaper/faster alternative for single facts or link lists. This is exactly the kind of clear contextual differentiation expected.

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

• extractA
  4.6/5.0
  Behavior5/5

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

  Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context: missing fields return null, values are never invented, it returns one object per link (up to 5), and cost per link. This goes beyond annotations and provides genuine behavioral insight without contradiction.

  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 well-structured with clear section headings (When, Schema, Returns, Cost) and is front-loaded with the core action. However, it repeats the full content in both Russian and English, doubling its length. This is acceptable for bilingual coverage but slightly verbose.

  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?

  Given the absence of an output schema, the description fully explains return values, batching (up to 5 links), alternatives, and cost. It covers both behavioral and semantic aspects required to use the tool correctly, making it complete for its complexity.

  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?

  The input schema already provides 100% parameter descriptions, including the shorthand and full JSON Schema formats. The description's schema section largely duplicates the schema text, adding no new parameter-specific meaning beyond what's already structured. Thus, the baseline of 3 is appropriate.

  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 reads a page and returns JSON strictly following the provided schema, with only the requested fields and no page text. It distinguishes itself from siblings by explicitly contrasting with read_url, making its purpose unmistakable.

  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 gives explicit 'use when' and 'do not use when' guidance, names the alternative read_url, and even compares cost (4× cheaper). This is exemplary usage guidance that helps an agent decide between tools.

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

• fetch_pageA
  4.7/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint, idempotentHint), the description discloses cost (3 credits), output format (inline image + file link + markdown), and context consumption ('The image consumes a lot of context, which makes this tool overkill for reading'). No contradictions with annotations.

  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 structured with clear markers ('When:', 'Do not use when:', 'Returns:', 'Cost:') and each sentence carries distinct information. Bilingual repetition is acceptable for internationalization but does not add bloat.

  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?

  Covers purpose, alternatives, cost, return types, context consumption, and use cases. No output schema is present, but the description adequately explains what the tool returns. Complete for a tool of this complexity.

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

  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 url and maxChars with meanings. The description does not add parameter-specific details beyond what the schema provides, hence baseline 3.

  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 opens with a specific verb and resource: 'Opens the page in a full browser and returns a screenshot as an inline image, a link to the full-size file, and the page text in markdown.' This clearly distinguishes it from read_url and extract by emphasizing the visual output (screenshot) and full-page text.

  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 'when to use' and 'when not to use' guidance, naming alternatives: 'Do not use when: you only need text — read_url (1 credit vs 3, and faster); you need specific values — extract.' This is ideal usage guidance.

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

• read_urlsA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description builds on this by disclosing partial success behavior (failed links do not fail the call, listed separately with error codes), duplicate/limit dropping with count, parallel fetching, and cost per link. No contradiction; this is rich behavioral context beyond the annotation hints.

  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 detailed yet well-structured: what, when/when-not, returns, and cost. Every sentence adds value, and the bilingual format is purposeful. It avoids fluff while covering all necessary aspects in a compact, front-loaded layout.

  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?

  With no output schema, the description sufficiently explains return values (text per page, 'not read' block with error codes) and handles edge cases (partial success, duplicates, over-limit). Combined with the annotations and thorough schema, the description makes the tool fully usable without additional inference.

  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?

  The input schema has 100% description coverage with detailed explanations for all three parameters (urls, engine, maxChars), including defaults and constraints. The description does not add parameter-specific semantics beyond the schema; it mentions cost and general usage, which are not parameter semantics. Baseline 3 is appropriate.

  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 the tool reads a batch of pages (up to 5) in parallel and returns each page's text as clean markdown. It explicitly distinguishes from read_url by noting it's the same operation but in a single call, and differentiates from extract which returns specific fields. This satisfies the specific verb+resource criterion and sibling differentiation.

  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 gives explicit when/when-not guidance: 'Use when: you have a list of links, e.g. the top web_search results.' It names alternatives: read_url for single pages, extract for specific fields, and notes extract also accepts a list. This is a clear, actionable usage policy.

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

• read_urlA
  4.8/5.0
  Behavior5/5

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

  Beyond the readOnlyHint/idempotentHint annotations, the description discloses meaningful behavioral traits: JavaScript execution for SPAs, default truncation at 4000 characters, cost of 1 credit, and engine escalation behavior. These are not available in structured data and greatly inform the agent.

  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 well-structured with clear sections and front-loaded purpose. The bilingual duplication doubles length, but each language version is concise and information-dense. Still slightly longer than necessary for an English-only model.

  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?

  Despite the absence of an output schema, the description fully covers what the tool returns (title and text), default limits, cost, and alternatives. It is complete for an agent to decide when and how to use it.

  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 already covers all parameters with clear descriptions (100% coverage). The description additionally clarifies default behavior (auto engine escalates, maxChars default 4000) and cost implications, which adds value beyond 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 it opens a single page by known URL and returns clean markdown text, distinguishing it from siblings like fetch_page (layout), read_urls (multiple pages), and extract (specific fields). The verb 'opens' and resource 'page' are specific.

  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 'Use when' and 'Do not use when' guidance with named alternatives (web_search, read_urls, extract, fetch_page). This is exactly what a good usage guideline should do.

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

• web_searchA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description goes beyond them by disclosing non-deterministic live results ('repeating the same query returns different results'), cost per call, output limitations (no page content), and the excerpts behavior that adds real text and saves follow-up calls. No contradiction with annotations; in fact, idempotentHint=false aligns with the live Results description.

  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 well-structured with clear sections: purpose, when to use, returns, cost. It is front-loaded with the core purpose, and every sentence adds value. However, it is bilingual (Russian + English), which essentially doubles the length; while valuable for the audience, it slightly reduces conciseness.

  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?

  The description is comprehensive for a 9-parameter tool with no output schema: it covers return format, limits, cost, live behavior, language coverage, and parameter nuances. The 'when not to use' guidance and excerpts hint make the tool fully usable without further research. Nothing critical is missing.

  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 has 100% parameter description coverage, so baseline is 3. The description adds extra nuance beyond the schema for key parameters: excerpts behavior and its cost-saving benefit, depth semantics ('flash' for a single fact), and the relationship between num and max results. It doesn't over-explain, but it compensates beyond the schema's dry definitions.

  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 uses a specific verb ('searches the live web') and resource ('web') and clearly states the output format: ranked list with title, link, snippet. It also distinguishes itself from siblings by mentioning 'live web' and 'Russian-language coverage.' This is a model of purpose clarity.

  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 'When to use' and 'When not to use' section is explicit and names specific alternatives: read_url for known URLs, extract for 2–5 specific values, deep_research for written answers. It even provides context like needing fresh facts past knowledge cutoff. This is exactly what usage guidance should be.

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

• get_usageA
  5/5.0
  Behavior5/5

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

  Annotations already declare read-only and non-destructive behavior, but the description adds crucial context: 'Cost: free — this call consumes neither quota nor rate limit, so call it freely.' It also discloses return values ('Returns: balance, quota used, reset time and the price list') since there is no output schema. No contradiction with annotations.

  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 English description is efficiently structured with a purpose statement, 'Use when' scenarios, returns, and cost. Every sentence earns its place, and the information is front-loaded. Though duplicated in Russian, the English portion is concise and well-organized.

  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?

  For a simple parameter-less tool, the description covers all necessary context: what it does, when to use it, what it returns, and that it's free. It is fully self-contained even without an output schema, making it complete for an agent to select and invoke correctly.

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

  Parameters5/5

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

  The tool has zero parameters, so baseline is 4. The description explicitly confirms this: 'Takes no parameters.' This removes any ambiguity and adds value beyond the empty input schema, warranting a 5.

  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's function: 'Shows the remaining balance, daily quota usage, when the window resets, and the price of every tool in credits.' This is a specific verb+resource combination that directly distinguishes it from sibling tools, none of which handle usage or balance.

  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 provides usage scenarios: 'Use when: a call failed with [rate_limited]...; the user asks about balance or spending; you are about to run a large batch...' This gives clear guidance on when to invoke this tool versus alternatives, fulfilling the dimension completely.

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