Server Quality Checklist

Tool Scores

• fetch_referenceB
  3.3/5.0
  Behavior3/5

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

  The description discloses that the tool returns structured data fields (title, headings, tables, etc.), which gives some behavioral insight. It does not mention failure modes, rate limits, authentication needs, or what happens with inaccessible pages, and annotations are absent.

  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 concise and well-structured, with the action stated first and the output details and downstream usage mentioned efficiently. No redundant or verbose 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?

  The description gives a clear high-level purpose and output format, and it hints at downstream integration. However, it lacks details about constraints on input, error behavior, or the depth of the structured extraction, leaving some contextual gaps for an agent deciding whether to invoke the tool.

  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?

  The schema provides no per-parameter descriptions. The description mentions 'maxTextChars' indirectly through the structured data output, but it does not explain the meaning of the parameter, its unit, or the effect of the minimum/maximum constraints. The 'url' parameter is obvious from context but not formally described.

  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 specific action 'Fetch a public web page' and distinguishes the tool from siblings by explaining that results feed into card tools. It does not explicitly name sibling tools it differs from, but the downstream use case clarifies its role.

  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 when to use the tool—when needing structured web content for card creation—but does not explicitly state when not to use it or how it compares to alternatives like read_local_file. The 'and so on' phrase is vague about the full range of downstream tools.

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

• create_list_cardB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It does disclose the core rendering behavior: nested ordered list with hierarchical numbering. But it does not mention notable interactive behaviors like tutorTerms underlining/hover or contextActions, which are only described in the schema.

  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 two sentences with no filler. It front-loads the operation and output format, then adds a practical usage note. 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?

  For a tool with an output schema, the description does not need to explain return values. The core usage is covered, and the more complex optional parameters (`tutorTerms`, `contextActions`) are documented in the schema. Some gaps remain around optional parameters and sibling differentiation, but overall the definition is reasonably complete.

  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 only 33%, and the tool description does not compensate. It hints at the nested `items` structure through 'nested ordered list card', but it does not explain `title`, `intro`, `subtitle`, or how nesting maps to `children`. Only `tutorTerms` and `contextActions` have schema-level descriptions.

  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 specific verb ('Render') and a specific resource ('nested ordered list card') with distinctive behavior (hierarchical numbering). It is clear about what the tool produces, though it does not explicitly distinguish it from sibling card tools by name.

  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 phrase 'Good for procedures, outlines, and curricula' gives useful intended-use context. However, it does not explain when to choose this over alternatives such as create_markdown_card or create_table_card, nor does it mention any exclusions.

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

• create_table_cardA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description bears the full burden for behavior. It discloses useful behaviors: delimiter auto-detection, newlines as optional cell markers, and URL cells becoming links. It also implies a balanced table normalization. Yet it does not mention behavior for when both rows and text are supplied, or any failure modes, making it sufficient but not rich.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose and then adds a single behavioral detail (URL links). It is efficient, with no redundant fluff, and every clause adds a distinct use-case or behavior. This is an example of concise, high-value prose.

  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?

  Given 11 parameters and one required field (title), the description covers two main input modes but does not touch on caption, subtitle, columns, headers, tutorTerms, contextActions, or linkColumns. Though output schema exists, the set of options is broad, and many are left to the schema's implicit meaning. For an agent to use all features correctly, more explanation would be needed, but it suffices for the common path.

  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 45%, and several parameters (columns, caption, subtitle, linkColumns, cellDelimiter) lack inline descriptions. The description adds meaning for text and cellDelimiter (auto-detected) and linkColumns (URL cells become links), but it ignores caption, columns, subtitle, and headers beyond what is in the schema. It compensates for some gaps but not the majority, so it meets the minimum but not more.

  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's purpose: 'Render an HTML table card from explicit rows, or convert loosely delimited text into a balanced table.' This is a specific verb plus resource, making it distinct from sibling creation tools like create_chart_card or create_form_card. The two modes (explicit rows vs. text) are named, adding specificity, though it doesn't explicitly name a different sibling or exclusion.

  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 two main use cases (structured rows or raw text conversion) and mentions auto-detection of delimiters, which gives some guidance. However, it does not explicitly state when to favor this over sibling card creators (e.g., for tabular data vs. charts) or provide any 'when not to use' guidance. Since siblings are numerous, a clearer routing could be expected, but the core instruction ('from explicit rows or text') is implied enough for basic use.

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

• create_form_cardA
  3.8/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 behavioral burden and delivers the critical trait: submission sends values back to the chat as the next prompt, optionally shaped by promptTemplate with {{fieldName}} tokens. This discloses the non-obvious side effect (values become a user message, not a tool result). Minor traits like required-field validation blocking submission are not covered, but the essential model is transparent.

  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 with zero filler: the render action leads, and the submission mechanism follows directly. Every clause earns its place, including the optional promptTemplate note.

  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 UI tool with no annotations and an existing output schema, the description covers the essential end-to-end flow: render, user fills, values become the next prompt. The contextActions behavior is already documented in the schema, and the output schema covers return values. The only gap is validation behavior for required fields, which is a minor omission for an interactive 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 description coverage is low (29%), and the description compensates for the most important semantics — fields' values round-trip into the conversation, and promptTemplate token substitution shapes the prompt. However, it adds no meaning for title, subtitle, description, or submitLabel, relying on their self-explanatory names rather than explaining their presentation role.

  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 ('Render') with a concrete resource ('a form card') and states its purpose ('to give the conversation context and direction'). The second sentence adds the defining behavior — submitted values return as the next prompt — which distinguishes it from sibling card creators. It doesn't explicitly name a sibling, but the interaction model is specific enough to select correctly.

  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 use case: render an interactive form when the conversation needs structured context or direction from the user. However, it offers no explicit when-not-to-use guidance or alternatives, and with siblings like mirror_web_form and submit_web_form also handling form-like input, a sentence routing the agent would materially help.

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

• submit_web_formA
  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 full burden of behavioral disclosure. It states the action (submit values), the encoding, and the return (HTTP status and snippet). However, it does not disclose potential side effects (e.g., submitting data could mutate server state) or mention authorization, rate limiting, or failure behavior. The clause 'real website form' hints at an actual external action, but more explicit disclosure would be safer for an agent. The constraint on when to call it is a good behavioral trait.

  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 sentence that front-loads the purpose and includes the usage constraint and return format. It is concise with no filler. The critical usage condition is placed early, making it easy for an agent to parse. Slightly more structure (e.g., separating the return statement) could improve readability, but as is, it is efficient.

  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 four parameters, two of which are nested objects, and no output schema, so the description must cover operational context. It states what it does, when to call it, and what it returns. However, it lacks guidance on error handling, side effects, or details about the structure of 'fields' and 'headers' beyond schema descriptions. Given the absence of annotations, an agent would benefit from explicit notes about the potential mutating nature of submitting a form. It is adequate but not comprehensive.

  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 schema provides descriptions for 'action' and 'fields' but not for 'method' or 'headers' (50% coverage). The description adds 'form-encoded GET or POST,' which clarifies the method parameter's purpose and its encoding format. However, it does not add meaning for 'headers' or provide additional detail on how 'fields' should be structured beyond the schema. Since the schema already documents half the parameters and the description clarifies method encoding, it meets the baseline but does not fully compensate for the undocumented parameters.

  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 'Submit' and the resource 'a real website form,' and specifies the encoding ('form-encoded GET or POST'). It distinguishes itself from the sibling card-creation tools by emphasizing this is an actual submission, and the reference to 'mirrored form card' implicitly connects it to mirror_web_form. 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 gives a clear condition for use: 'Only call this with data the user entered in a mirrored form card, or values the user explicitly confirmed.' This provides a strong guardrail. It doesn't explicitly name alternatives or say when not to use it, but the constraint implies it should be used only after mirror_web_form and with user consent. Evidence: 'Only call this...'.

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

• create_chart_cardA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses the output behavior (SVG chart, legend, collapsible data table) but does not explicitly state that this is a mutating operation inserting a card into the host UI, nor any side effects. This is partial transparency, so a middle score is appropriate.

  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 short sentences front-load the action and output, list chart types, and add a use case without repetition or filler. Every phrase 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?

  For a 10-parameter tool with an output schema and no annotations, the description plus the rich schema is nearly sufficient: required inputs are trivial, the data-parameter schemas are described, and the use case is stated. Minor omissions like explicit chart-type selection guidance prevent a 5.

  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 50%, so the baseline is 3. The description adds no parameter-level guidance, but the schema already describes labels, series, values, tutorTerms, and contextActions; remaining params like title, type, and subtitle are semantically obvious. The description does not undersell the parameters.

  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 names a specific action ('Render'), a concrete resource ('SVG chart card'), and enumerates the supported chart types (bar, line, pie, donut). It clearly differentiates this tool from the table, list, and markdown card siblings by focusing on chart rendering with a legend and collapsible data table.

  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 sentence 'Use for useful graphics summarizing referenced data' provides a clear, actionable context for when to invoke the tool. It does not explicitly name alternatives or exclusions, but the context is specific enough to route an agent toward this card type over table/list/markdown siblings.

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

• create_tab_cardA
  4/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 behavioral transparency burden. It discloses that the card is interactive, tabbed, and supports plain text, HTML, and code with a copy button. It does not mention behaviors like HTML sanitization or tutor-term hover interactions, though those are already documented in the schema fields, so the gap is moderate rather than severe.

  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 well-structured sentence that front-loads the core operation, then provides concrete examples and content-type options. Every phrase earns its place and there is no filler or repetition of schema details.

  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's core purpose is clearly explained, and the schema richly documents the optional tutorTerms and contextActions behaviors, while an output schema is present. The main missing piece is explicit guidance on when to prefer this over sibling card tools, but for a card-rendering tool with modest complexity this is adequately complete.

  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 40%, so the description should compensate for undocumented parameters. It adds useful semantics for the core 'tabs' parameter: tabs are different contexts of the same subject and can hold text, HTML, or code. However, it does not add meaning for title, subtitle, tutorTerms, or contextActions beyond what the schema already documents, so compensation is partial.

  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 ('Render') and resource ('interactive card with tabs'), and explains the organizing principle: tabs show different contexts of the same subject with examples like programming language, OS, or skill level. This clearly distinguishes it from sibling card tools such as create_table_card, create_chart_card, or create_video_card.

  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 clear context for when this card is appropriate: when the user needs multiple perspectives on the same subject, e.g., one tab per language or OS. It does not explicitly name alternatives or state when not to use it, but the use case is specific enough for an agent to route correctly.

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

• create_video_cardA
  4.2/5.0
  Behavior3/5

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

  No annotations were provided, so the description carries the transparency burden. It explains why streaming pages fail (video element pointed at a player page), which is useful behavioral context蓬莱. However, it doesn't mention the output/card format, side effects, or limits on file size. The main behavioral constraint (source type) is well-covered, but other runtime behavior is not described.

  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. The first immediately states the action and the key constraint. The second explains the rejection rule and points to the alternatve tool. No wasted words.

  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 description covers the essential constraint on src, which is the most error-prone parameter, and named the sibling tool for animations. It doesn't describe the return value, but an output schema exists. Minor gap: no mention of required vs optional fields like title, but the schema lists required. Good overall.

  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 schema explains 5 of 9 parameters (src, poster, autoplay, contextActions; loop and muted have only type). The description adds critical detail for src (direct video file only, reject streaming URLs) and ties to the card rendering. That compensates for the low schema coverage on the most important param, but the others remain thin. A middle score is fair.

  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 precise verb and resource: 'Render a card with an HTML video player for a short clip.' It immediately distinguishes the tool from siblings by specifying the target format (video file) and the explicit exclusion of streaming-platform URLs, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  It states the hard constraint: src must be a direct video file, and explicitly lists what is rejected (streaming URLs) with the reasoning. It also names the alternative tool (create_animation_card) and the condition for using it, so an agent can classify inputs correctly.

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

• mirror_web_formA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and does reasonably well: it discloses the side effects (fetching, extracting, rendering, returning a structured payload on submission) and a limitation ('public web page'). It omits details like rate limits, failure behavior, or handling of pages without forms, but the core workflow is transparent.

  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 well-ordered: action, object, output flow, and downstream purpose. Every clause contributes indispensable information, with no filler or redundantly repeated schema details.

  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 the tool's complexity and the absence of annotations, the description gives the agent a complete mental model of the execute-and-submit loop, and the presence of an output schema covers return details. It remains slightly thin on edge cases like 'page has no forms' or 'multiple matching forms,' but it is still sufficiently complete for correct tool selection and invocation.

  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 schema already documents title and formIndex, and the description adds some contextual meaning—especially that the URL must point to a public page and that a single form is extracted. However, it mostly relies on the schema for parameter specifics rather than enriching them, so the added value is moderate.

  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 names a specific verb-resource pair: fetch a public web page, extract one of its forms, and render it as an interactive card. It also distinguishes itself from the sibling submit_web_form tool by describing how the card payload feeds into that separate submission step.

  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 clearly conveys when to use the tool: when a website form should be mirrored into the conversation so a model-created task can later submit it. It even names the follow-up tool (submit_web_form), which gives strong routing context, though it does not explicitly state exclusions such as 'use create_form_card for manually built forms.'

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

• unpack_archiveA
  4.2/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 behavioral disclosure. It does well: it explains that the path is resolved on the server machine, not in the caller's sandbox, and that build caches and binary entries are skipped. It does not mention permissions, rate limits, or whether anything is written to disk, but the core behaviors 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, all carrying substantive information. The main behavior is stated first, followed by the important environment safety note and the skip policy. No filler or repetition.

  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 description is sufficiently complete for a moderately simple tool: it defines the operation, the environment constraint, and the filtering behavior. No output schema exists, but because the description says 'return the contents of its text files', the return concept is explained reasonably. It does not specify the output format or potential edge cases, but these are minor 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 description coverage is low (33%), but the description adds critical semantics for the required 'path' parameter by emphasizing server-side resolution. The 'include' parameter already has a schema description; maxFiles only has numeric bounds, but the tool's purpose implies it limits the number of inspected files. The description partially compensates but does not fully document all parameters.

  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 and resource: 'List a zip archive's entries and return the contents of its text files.' This is unambiguous and clearly distinguishes the tool from siblings like read_local_file by describing a zip-inspection workflow.

  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 described use case—'so a project can be inspected and turned into cards'—gives clear context for when to call this tool. It does not explicitly name alternative tools or state when not to use it, but the purpose is obvious enough for an agent to choose it appropriately.

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

• create_animation_cardA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden (baseline 3). It goes beyond by disclosing: scenes play sequentially in a 16:9 stage with controls, everything is procedurally generated (text, SVG shapes, CSS animation) with no external assets, and shows how to handle variations via per-scene transitions/durations. It misses some edge cases (e.g., what happens if scenes is empty – though schema enforces minItems 1), but the disclosed behavioral traits are rich and accurate.

  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 substantial but every sentence earns its place, covering what, why, and how to compose scenes. It could arguably be front-loaded more (the key 'when to use' is first, which is good). Minor deduction for density - an agent might need to parse carefully - but no fluff.

  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 the tool's complexity (nested scenes, transitions, shapes, charts) and the rich schema, the description does an excellent job of tying it together. It explains the animation model (sequential scenes, transitions), provides patterns (title reveal, chart zoom), and even implies limits (no external assets means you can't rely on images). Not a 5 because it doesn't explicitly document error cases or fallbacks, but for the complexity it covers the essentials 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 63%, so the schema itself documents most parameters. The description adds value by implying how scenes (structure of shapes, bullets, chart) relate to the animation, and clarifies the 'no external assets' constraint that affects how to fill scene content. However, it does not directly explain the semantics of properties like durationMs, loop, or autoplay beyond what the schema already states, so it doesn't fully bridge the 37% 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 uses a specific verb ('Render'), identifies the resource (a short animated clip as a card), and clearly distinguishes when to use it: when no direct video URL exists but motion would communicate better. It also differentiates from siblings like create_video_card by emphasizing generated content (text, SVG, CSS) over external assets, which is a strong differentiator visible in the sibling list.

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

  Usage Guidelines5/5

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

  The first sentence explicitly states the primary use case and contrasts with the alternative ('when no direct video URL exists'). It also gives composition guidance ('Compose classic clip patterns and vary them per conversation') and lists concrete examples that heavily imply when to use this over a static card. While it doesn't name a specific sibling, the 'no direct video URL' contrast with create_video_card is an explicit exclusion condition.

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

• create_reveal_cardA
  4.3/5.0
  Behavior4/5

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

  The description explains rendering details: code fields become monospace blocks with a copy button, tutor terms render as underlined micro-tips with longest-first matching and case-sensitivity. No annotations provided, so the description carries the burden and does it well. It could mention more about interactions beyond the described behaviors, but it's solid.

  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?

  Description is focused and dense, listing use cases and key behavior without verbose filler. The tutorTerms description is long but necessarily detailed for precise matching semantics.

  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?

  Covers what the card does, when to use it, and rendering details. Lacks explicit when-not-to-use and alternatives, but with no annotations and a complex schema, it's adequately 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.

  Parameters4/5

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

  The schema covers parameter types and minItems, and the description adds meaning: code renders as monospace with copy button, text is plain, tutorTerms matching rules. Some params like subtitle and open are left plain, but overall usage is clear.

  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 names a specific deliverable — a card of collapsible show/hide sections with show-all/hide-all buttons — and lists concrete use cases (step-by-step guides, FAQs, spoilers, long reference material). This makes the tool's purpose unambiguous and distinct from typical siblings like tab or code-tour cards.

  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?

  It explicitly says it's good for step-by-step guides, FAQs, spoilers, and long reference material, which gives clear usage context. It does not name alternatives or state when NOT to use it, so it stops short of full guidance.

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

• read_local_fileA
  4.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. It discloses size caps, binary refusal, and filesystem confinement, which are critical behavioral traits. It doesn't detail error handling or exact return format, but the key constraints are well 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?

  The description is compact, with each sentence adding value: purpose, remote bridge caveat, size/binary limits, and configuration. It's front-loaded with the core purpose and efficiently covers all key points without fluff.

  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 simple read tool with two parameters and no output schema, the description covers purpose, constraints, and configuration. It lacks explicit return format details, but given the tool's simplicity and the absence of an output schema, the description is largely sufficient for an agent to call it correctly.

  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 0%, so the description must compensate. It explains the 'path' parameter's context (server filesystem) and implies 'maxChars' via size caps, though it doesn't explicitly name maxChars. The description adds meaning beyond the bare schema, but could be more explicit about maxChars.

  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 text file from the server's filesystem for review and card integration. It distinguishes itself from siblings by focusing on local file access, which is unique among the listed card creation and web tools.

  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?

  It explicitly warns about remote bridge scenarios, advising to pass text directly to the card tool instead. It also mentions size caps and binary refusal, and provides configuration guidance via MCP_CHAT_CARDS_FS_ROOT, giving clear when-to-use and when-not-to-use context.

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

• create_code_tour_cardA
  4.7/5.0
  Behavior5/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: file ordering (explicit files keep order with README/manifests hoisted, archives use a specific order), the packing behavior (parts of ~32,000 rendered characters regardless of file count, so even a handful of medium files splits), and the pagination protocol (parts.current/total/hasMore, with explicit instructions to call again with part: current+1). It also discloses that matching is case-sensitive and terms are plain text. This is rich, actionable behavioral context.

  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 fairly long but packs in essential behavior. It front-loads the main purpose and the ordering/participation logic. However, some redundancy exists: the part parameter is described both in the description and in the schema, and the tutorTerms matching rules are detailed but necessary. It could be tightened, but no sentence is wasted; the length is justified by the complexity.

  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 complexity of this tool (11 parameters, multiple modes, pagination, tutor term matching), the description is remarkably complete. It covers the main behavioral quirks (splitting, ordering, case-sensitivity, machine distinction), and the output schema exists to document the return values. The description plus schema cover everything an agent needs to call this tool correctly, including the pagination loop.

  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 73%, so the schema already documents many parameters. The description adds value for ambiguous or under-documented parameters: it explains the packing behavior for parts, the ordering logic, the archivePath machine caveat, and the tutorTerms matching rules (case-sensitive, longest first, not in code samples). It doesn't cover every param (e.g., maxTabs, contextActions aren't described), but the description's comments on key parameters like part, archivePath, and tutorTerms go beyond 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 renders a project's source as an interactive card with one tab per file, including copy buttons. It distinguishes itself from sibling card-creation tools (create_chart_card, create_tab_card, etc.) by focusing on source code rendering and specifically mentions the code-related features.

  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 provides explicit guidance on when to use this tool vs alternatives: it explains the two modes (passing a zip archive vs passing files explicitly), notes the machine-location caveat for archivePath over a remote bridge, and mentions the alternative of passing files when the archive exists only on the caller's side. It also addresses the pagination workflow implicitly.

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

• create_markdown_cardA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure, and it delivers. It explicitly warns that raw HTML is shown as literal text, explains that long documents split at H2 boundaries into ~32,000-character parts, and tells the caller how to detect remaining parts via structuredContent.parts. This goes well beyond the title and gives the agent actionable expectations about side effects and output.

  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 dense but efficient: a concrete first sentence, input options, one important formatting caveat, and a clear explanation of splitting behavior. No sentence is wasted, and the most important behavioral facts are front-loaded.

  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 covers the tool's rendering behavior, input alternatives, the raw-HTML limitation, split behavior, and how to check for remaining parts. Given the rich input schema and presence of an output schema, an agent has enough context 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.

  Parameters4/5

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

  Schema description coverage is high (89%), so the schema already documents most parameters. The description adds valuable semantics by explaining the either-or relationship between markdown and path, the splitting behavior tied to part, and the constraint that path refers to the machine running the server. This supplements rather than merely restates 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 opens with a specific verb and resource: 'Render a markdown document as one interactive card.' It then lists concrete affordances (tables become card tables, code gets copy buttons, H2 sections fold into reveals) that make the tool's purpose unmistakable. It also distinguishes it from sibling card creators by tying it to markdown input.

  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 clearly communicates when to use the tool: pass either markdown content or a previously generated markdown file. It also gives practical guidance about using markdown syntax because raw HTML is not rendered. It does not explicitly name alternative card-creation tools, but the input source and rendering behavior make the intended use unambiguous.

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

• get_insert_bookmarkletA
  4.9/5.0
  Behavior5/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 thoroughly discloses the bookmarklet's behavior: insertion is cosmetic, page-local, gone on reload, and not part of conversation history. It also clarifies the prerequisite step (copying a card) and the mechanism (right-click menu). This is exemplary transparency.

  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, dense sentence that front-loads the purpose, then explains the mechanism and context. Every clause earns its place, providing essential context without redundancy.

  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 tool has no output schema, but the description fully covers what the agent needs: what the tool returns, when to call it, why it's needed, and the behavior of the result. There are no gaps for a 0-parameter retrieval tool.

  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, so the baseline is 4. The description adds context about the tool's invocation but not parameter semantics since there are none. This matches the rubric for a 0-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 tool's purpose: to return the Insert Card bookmarklet and usage instructions. It explicitly names the verb 'Return' and the resource 'bookmarklet', and distinguishes it from sibling tools (which create cards or handle files) by explaining the specific scenario it addresses.

  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 usage guidance: 'Call this when the user asks how to place a card at an arbitrary spot on the page.' It also explains the underlying context (browser limitation) and why the bookmarklet is needed, leaving no ambiguity about when to invoke it.

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