John's Essentials

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

Annotations already declare readOnlyHint=true, and the description adds the specific set of extracted audio properties, including waveform data. This gives the agent a concrete sense of what will happen without contradicting the read-only annotation. It stops short of describing output format or limits, but annotations lower the bar here.

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

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

The description is a single, compact sentence with the action and resource front-loaded, followed by a useful property list. The 'Audio Analyzer —' prefix is redundant with the title, but the remaining text earns its place without bloat.

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

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

For a single-parameter, read-only analysis tool with no output schema, the description provides the expected return dimensions and the schema handles input format documentation. It could mention output format or file-size constraints, but nothing essential is missing for correct selection and invocation.

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

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

Schema description coverage is 100%: the file parameter is already documented as an input file with accepted formats (MP3, WAV, AAC, FLAC, OGG). The description adds no additional parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Analyse') and resource ('audio file'), then enumerates concrete output dimensions: duration, sample rate, bit rate, channels, codec, and waveform data. This clearly distinguishes the tool from generic analyze_file and sibling tools like analyze_video.

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

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

The description gives clear context: use this tool when audio properties are needed. It does not explicitly name alternatives or exclusions, but the strong audio-specific framing and property list make the intended use obvious among the many analyze_* siblings.

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

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

The readOnlyHint annotation aligns with the non-destructive 'Extract' wording, and the description adds the 'dominant' nuance for color selection. However, it does not describe output format, limitations, or behavioral edge cases beyond what annotations already imply.

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

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

The description is one compact, front-loaded sentence with the core action stated immediately. The category tag is useful navigation context, and there is no unnecessary filler.

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

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

For a simple read-only extraction tool, the description plus fully described schema is mostly sufficient for invocation. However, with no output schema, it does not mention what the returned palette looks like or any selection behavior beyond 'dominant', and it lacks explicit sibling differentiation.

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

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

Schema description coverage is 100%, with both 'file' and 'colors' already fully documented by the input schema. The description adds little parameter meaning beyond the word 'dominant', so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Extract') and a specific resource ('dominant colour palette from an image'). This clearly distinguishes it from the many sibling analyze_* and photo_* tools, such as analyze_image_quality or photo_color_adjuster.

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

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

The description implies when to use the tool by naming its exact purpose, but it does not explicitly state when to prefer it over alternatives or provide any exclusions. An agent can infer usage, but not from explicit guidance.

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

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

Annotations already mark the tool as readOnlyHint=true, and the description adds useful behavioral detail by specifying what the analysis produces. It does not contradict annotations, and it gives the agent a concrete picture of the tool's observable output.

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

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

The description is a single front-loaded sentence that communicates the action and output details efficiently. Minor redundancy exists in repeating 'CSV Analyzer' and the trailing '[category: analyze]' tag, but overall it is appropriately compact.

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

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

For a low-complexity tool with one documented parameter, no output schema, and read-only annotations, the description is sufficiently complete. It tells the agent what inputs are expected and what analytical results will be returned, which is enough to decide on and invoke the tool.

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

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

Schema description coverage is 100% and the only parameter, 'file', is already described as 'Input file (CSV)'. The description does not add extra meaning to the parameter, so it stays at the baseline for full schema coverage.

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

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

The description explicitly states the verb 'Analyse' and the resource 'CSV file', then enumerates the exact analysis outputs: row/column count, data types, null counts, and min/max/mean per column. This makes it clearly distinguishable from generic siblings like analyze_file.

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

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

The description gives no guidance about when to choose this tool over sibling analyzers, nor any exclusions. It simply states what the tool does. With many analyze_* siblings present, an agent gets no help selecting among them.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the perceptual-hashing mechanism, which implies approximate matching rather than byte-level comparison. It does not disclose result format, similarity threshold, or behavior on mixed file types, but the schema's note about silently ignoring files beyond 20 covers the main edge case.

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

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

A single tight sentence that front-loads the purpose before the method. The 'Duplicate Detector —' prefix slightly redundantly repeats the tool name, but there is no other wasted content, and the key discriminator (perceptual hashing) is included.

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

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

For a one-parameter, read-only analyze tool with a fully documented schema, the definition covers the essential context: what it does, how it does it, and the input constraints. The main gaps — return value shape and near-duplicate threshold — are minor for an analyze-category tool with no output schema and would likely be observable at runtime.

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

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

Schema description coverage is 100%: the 'files' parameter already documents the 2-20 range, accepted types, and silent-ignore behavior. The description's 'batch upload' phrasing adds minor framing but no new semantic detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb ('Identify'), a specific resource ('duplicate or near-duplicate files in a batch upload'), and the method ('perceptual hashing'). This distinguishes it from siblings like analyze_hash (plain hashing) and analyze_image_similarity (image-specific similarity) — an agent can tell what this tool does without opening the schema.

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

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

The phrase 'in a batch upload' implies the intended scenario (comparing a set of files at once), and the schema's 2-20 file range reinforces this. However, the description gives no explicit when-to-use vs. when-not-to-use guidance and names no alternatives, leaving the agent to infer the boundary against near-siblings like analyze_image_similarity and analyze_hash.

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

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

Annotations already mark readOnlyHint=true, and the description reinforces this by explicitly stating the tool only reports and does not convert or rewrite the file. It also adds useful behavioral context about what kinds of files and encoding issues it addresses. The description aligns with and slightly extends the annotation-provided safety profile.

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

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

The description is compact and front-loaded, starting with a clear one-line summary followed by a practical use case and an explicit scope limitation. Every sentence earns its place, and the category tag is unobtrusively appended.

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

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

For a simple, single-parameter, read-only detector tool, the description covers the trigger scenario, supported encodings, input file types, and the boundary of what it does not do. No output schema exists, but the description's 'reports the encoding only' sufficiently conveys the outcome. Nothing critical is missing.

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

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

The single parameter 'file' is already fully documented in the schema with type, format, and accepted extensions (TXT, HTML, CSV, XML), so schema coverage is 100%. The description adds no new parameter-specific semantics beyond listing example encodings, which is marginal value. Baseline 3 is appropriate.

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

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

The description clearly identifies the specific action 'Detect the character encoding' and the resource 'text or HTML file.' It also distinguishes itself from conversion tools by stating 'It REPORTS the encoding only — it does not convert or rewrite the file,' making its purpose unmistakable among the large sibling set.

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

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

It provides an explicit trigger condition: 'Use when accented letters, apostrophes or quotation marks arrive as garbled symbols.' It also clarifies what it does not do, so an agent knows not to use it for conversion or rewriting. However, it does not name specific alternative tools or state when not to use it beyond the conversion exclusion.

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

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

Annotations already declare readOnlyHint=true, so the tool's safety profile is clear. The description adds useful behavioral context beyond the annotations by specifying the exact output facets the analysis returns (type, encoding, size, MIME type, magic bytes, structure summary). It does not disclose limitations like file size limits, but the low-risk read-only nature makes that acceptable.

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

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

The description is one front-loaded sentence that immediately states the action and the return values. The 'File Analyzer —' prefix redundantly repeats the tool name and the '[category: analyze]' tag adds marginal value, but there is no meaningful padding or wasted prose.

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

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

For a simple one-parameter read-only tool with no output schema, the description covers the essential information: what the tool does and what it returns. The lack of explicit guidance about specialized sibling tools is a gap, but the low complexity and full schema coverage keep the definition reasonably complete.

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

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

The schema has 100% description coverage: the single binary 'file' parameter is documented as 'Input file (any)'. The description adds no extra parameter-level details, so the baseline score of 3 is appropriate since the schema fully handles parameter semantics.

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

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

The description uses a specific verb ('Analyse') and names the resource ('a file') while enumerating concrete outputs: type, encoding, size, MIME type, magic bytes, and structure summary. However, it does not explicitly distinguish itself from specialized sibling analyzers such as analyze_metadata or analyze_encoding_detector, leaving some ambiguity about which tool to choose for a generic file.

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

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

The generic phrasing 'Analyse a file' and the '[category: analyze]' tag imply this is a general-purpose analyzer, but there is no explicit statement about when to use it instead of specialized tools like analyze_audio, analyze_csv, or analyze_pdf_inspector. No alternatives or exclusions are mentioned, so the agent must infer usage context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds real behavioral value by disclosing the pairing constraint ('Provide one complete pair') — which matters because the schema lists 0 required parameters — and by specifying line-by-line output granularity. This is context the agent would not get from annotations alone.

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

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

The core action is front-loaded and the critical pairing requirement is distilled into one short imperative sentence. Minor redundancy exists — the 'File Diff —' prefix restates the annotation title and '[category: analyze]' adds little — but these are small tokens of noise in an otherwise tight definition.

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

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

For a simple read-only tool with four self-documenting parameters, the description covers the essential operational trap (modes and pairing) and indicates the result shape ('line-by-line diff'), which partly compensates for the missing output schema. It would benefit from return-format or input-limit details (e.g., handling of binary inputs, size caps), but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, and each parameter is already described, including the file-mode and text-mode pairing hints on file_a and text_a, so the baseline is 3. The description's 'Provide one complete pair' reinforces the schema's existing mode guidance rather than adding new per-parameter meaning.

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

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

The description uses a specific verb ('Show') and resource ('line-by-line diff between two text files or two pasted texts'), and clearly delimits the tool's scope. Among dozens of analyze_* siblings, it is easily distinguishable as the text-diff tool, especially against photo_image_diff (image diff) and analyze_file (generic file analyzer).

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

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

The description clearly states how to invoke the tool — one complete file pair or one complete text pair — which is useful operational guidance. However, it never names alternatives or exclusion conditions (e.g., no mention of photo_image_diff for images, or a warning against binary inputs), so when-to-use vs alternatives is only implied.

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

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

The readOnlyHint annotation already communicates that this is a non-mutating operation. The description adds useful behavioral context by limiting inputs to PDF/DOCX and excluding images, but it does not disclose additional behaviors such as output format, behavior on unsupported files, or font-detection limitations.

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

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

The description is a single compact, front-loaded sentence. It leads with the tool's role, follows with accepted formats, and ends with the key exclusion. No unnecessary filler or repetition of schema details.

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

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

For a simple one-parameter, read-only tool with no output schema, the description adequately covers the core scenario: input file types and an important unsupported case. It does not detail return structure, but the tool name and action make the expected output reasonably clear.

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

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

The schema already documents the single 'file' parameter as PDF/DOCX input, so the description is not the only source. However, it adds meaningful semantic value by explicitly stating that images are unsupported, which clarifies the accepted input domain beyond the schema.

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

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

The description clearly states the action ('Detect fonts') and the resource scope ('PDF or DOCX document'), with an explicit exclusion of images. This makes it unmistakable what the tool does and distinguishes it from the many sibling analyze_* tools.

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

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

The description provides clear when-to-use context: any PDF or DOCX where font detection is needed. It also gives a when-not-to-use signal by explicitly stating that images are not supported, though it does not name a specific alternative tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds meaningful behavioral context beyond that: it uses a hybrid LanguageTool + Grok pipeline, produces rule citations, enforces style guides and dialects, and reports per-issue severity. It does not fully describe output format or the implications of sending text to an LLM, but the added detail is substantial.

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

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

The description is a single dense sentence that packs substantial information without rambling. It loses some polish due to redundancy: 'Grammar Checker — ... grammar checker' repeats the core noun, but overall it is efficient and front-loaded with the tool's main function.

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

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

With no output schema present, the description partially compensates by mentioning rule citations, style-guide awareness, dialect enforcement, and per-issue severity, which hint at the return shape. However, it does not explicitly describe the output structure, result format, or how to distinguish single-text use from the batch sibling, leaving moderate gaps for an agent.

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

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

Schema description coverage is 100%, and the schema already documents all five parameters, their enums, defaults, and descriptions. The description's mention of style guides, dialects, and severity aligns with parameters like style and dialect, but it does not add meaningful parameter-level semantics beyond what the schema already provides.

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

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

The description clearly identifies the tool as a grammar checker with specific capabilities: hybrid LanguageTool + Grok processing, rule citations, style-guide enforcement, dialect handling, and per-issue severity. It is not a vague restatement, but it does not explicitly distinguish itself from the sibling analyze_grammar_check_batch tool, preventing a 5.

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

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

The description implies usage through its feature list but provides no explicit guidance on when to choose this tool over alternatives. In particular, it does not mention the batch sibling or any exclusion criteria, leaving the agent to infer the single-text scope from the tool name and schema.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety and closed-world profile. The description adds useful behavioral context about the 20-item batch limit and per-item style/dialect/mode support, but it does not explain what 'hybrid' means or what the response contains.

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

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

The description is a single concise sentence with the key capability front-loaded. Minor redundancy exists because 'Grammar Checker (Batch)' repeats the title, and the closing '[category: analyze]' tag is not essential for invocation.

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

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

For a one-parameter tool with a fully documented input schema, the description is adequate for invoking the tool. However, there is no output schema and no description of return values, and the distinction from analyze_grammar_check is only implicit, leaving some contextual gaps.

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

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

Schema description coverage is 100%, so the schema already documents the items parameter and its nested properties. The description only restates that per-item style, dialect, and mode are supported, adding little beyond the schema.

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

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

The description states a specific action ('Run the hybrid grammar checker') and resource scope ('across up to 20 texts in one call'), which clearly distinguishes it from the single-item sibling analyze_grammar_check. The 'Batch' label and the per-item options make the tool's role unambiguous.

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

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

The description implies batch usage via 'up to 20 texts in one call' and clearly frames the tool as a batch operation. However, it does not explicitly say when to prefer this over analyze_grammar_check or when to use the single-item variant, leaving the choice to inference.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to justify safety. It adds useful context about the supported hash algorithms and file input scope. However, it does not disclose output format, limits, or the fact that a direct text alternative exists 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.

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

The description is a single compact sentence that front-loads the core purpose and algorithm list. The opening 'Hash Generator (File)' partially repeats the title, but the overall content is efficient and free of filler.

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

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

For a simple read-only hashing tool, the description is mostly adequate: it names the algorithms and input type. However, there is no output schema and the description does not mention return format, nor does it acknowledge the text-input alternative, which is a notable gap.

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

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

Schema description coverage is 100%: both 'file' and 'text' have descriptions in the schema. The tool description adds no new parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb ('Compute') and resource ('hashes of an uploaded file') and explicitly lists MD5, SHA-1, SHA-256, and SHA-512. This clearly distinguishes it as a file-hashing/analysis tool, though it does not explicitly contrast it with the sibling generate_hash.

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

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

The description gives a clear scenario—computing hashes of an uploaded file—but provides no guidance on when to use this tool versus alternatives like generate_hash or analyze_file. There are no exclusions, prerequisites, or explicit routing to other tools.

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

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

Annotations already declare readOnlyHint=true, and the description adds behavioral detail by enumerating exactly what the tool computes. It does not discuss output format or file size limits, but for a read-only analyzer these gaps are minor.

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

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

The description is a single efficient sentence with the core operation front-loaded and no filler. The leading 'Image Quality Analyzer' phrase slightly duplicates the tool title/annotation, keeping it from a perfect score.

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

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

For a one-parameter, read-only analysis tool, the description sufficiently explains what the tool does and what metrics it returns. It omits the exact return format, but the listed metrics are 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.

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

Schema description coverage is 100%: the only parameter, 'file', is already documented with accepted formats. The description's phrase 'of an image' adds little semantic value beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb, 'Measure', and names four concrete outputs: sharpness, noise level, compression artefacts, and BRISQUE quality score. This clearly distinguishes it from sibling tools like analyze_image_similarity or analyze_metadata.

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

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

The description provides clear context: use this tool when you need objective image quality metrics. It does not explicitly mention alternatives or when-not-to-use conditions, so it stops just short of full routing guidance.

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

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

Annotations already cover read-only safety (readOnlyHint=true), and the description adds the algorithmic context that 'similarity' means pHash distance, which is genuinely useful. It also clarifies that file_a and file_b must be separately-named uploads, a non-obvious calling trait. However, it does not disclose the output score's range, direction, or thresholds, leaving result interpretation ambiguous.

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

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

A single front-loaded sentence that leads with the core purpose, then the calling detail, then a category tag — no filler. The only redundancy is restating the exact title 'Image Similarity' at the start, which is a minor deduction.

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

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

For a low-complexity, read-only tool with fully documented parameters, inputs and core behavior are adequately covered. The notable gap is the absence of an output schema combined with no description of the score's format or interpretation, which an agent needs to judge how to use the result. Adequate but not fully complete.

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

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

Schema description coverage is 100%, both binary params are documented with accepted formats (JPG, PNG), so the baseline of 3 applies. The description adds only the minor clarification that the two uploads must be separately named, which is a small enhancement over the schema.

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

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

States a specific verb ('Compute') and resource ('perceptual similarity score between two images'), and pins down the method (pHash distance). The pHash detail implicitly differentiates it from siblings like photo_image_diff (pixel diff) and analyze_image_quality, so an agent can tell them apart without opening any schema.

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

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

No guidance on when to choose this tool over its many related siblings (photo_image_diff, analyze_image_quality, describe_image, etc.). There are no conditions, exclusions, or alternative tool names. The only operational hint — that inputs are two separately-named uploads — concerns calling convention, not tool selection.

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

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

The readOnlyHint annotation already establishes safety, and the description adds useful behavioral context: it extracts ALL hyperlinks, supports pasted text, and falls back to raw-text scanning for unsupported file types. This goes beyond the structured annotation without contradicting it.

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

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

Two sentences deliver the core action, supported inputs, and fallback behavior, with the key purpose front-loaded. Minor redundancy exists because 'Link Extractor' repeats the title and the '[category: analyze]' tag adds metadata without advancing agent understanding.

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

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

For a low-complexity, read-only tool with fully described parameters, the description is complete enough to invoke correctly: it states what is extracted, from which sources, and how other types are handled. There is no output schema, but 'extract all hyperlinks' adequately conveys the return concept, so no critical invocation information is missing.

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

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

Schema description coverage is 100% for both file and text parameters, and those schema descriptions already define the binary file format and the text/HTML alternative. The tool description mostly restates this information, adding no new parameter-level meaning, so the baseline 3 applies.

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

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

The description uses the specific verb 'Extract' with the resource 'all hyperlinks' and names the input sources (PDF, HTML, pasted text). This clearly differentiates it from generic siblings like analyze_file and analyze_pdf_inspector by scope and output, even without naming a sibling.

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

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

It states supported input types and the raw-text fallback for other files, so the intended context is clear. However, it never says when to prefer this tool over related alternatives such as analyze_file, analyze_pdf_inspector, or web_scrape_page, nor does it give explicit exclusions.

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

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

The readOnlyHint annotation already establishes that this is a safe, read-only operation. The description adds useful scope by enumerating metadata types, but it does not disclose output format, potential limitations of 'all metadata', or how results are returned, leaving a moderate behavioral gap.

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

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

The description is a single, front-loaded sentence with useful examples and no fluff. The 'Metadata Viewer —' prefix is slightly redundant with the annotation title, and the '[category: analyze]' tag adds minimal value, which keeps it from a perfect score.

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

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

For a low-complexity tool with one required parameter, a readOnlyHint annotation, and a simple 'display all metadata' output concept, the description is mostly sufficient. The lack of an output schema and any mention of output format or supported file limitations is a minor gap, but not enough to make the tool hard to invoke.

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

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

Schema coverage is 100%: the only parameter, 'file', is already described as 'Input file (any)'. The description adds the context that the file's metadata will be extracted, but it does not add format, size, or encoding semantics beyond what the schema already provides.

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

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

The description states a clear action ('Extract and display') on a well-defined resource ('all metadata from a file') and gives concrete metadata categories (EXIF, PDF info, document properties, audio tags). It does not explicitly distinguish itself from siblings like photo_exif_viewer or pdf_get_metadata, so it stops short of full sibling differentiation.

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

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

The description implies usage: use this when you need general metadata from a file. However, it provides no explicit guidance about when to choose this instead of the more specialized metadata-related siblings, nor does it mention any exclusions or prerequisites.

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

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

The description is consistent with readOnlyHint:true and openWorldHint:false, and 'inspection' signals no mutation. It adds the scope of what is read but does not disclose potential limits like file-size restrictions, authentication needs, or response format. Because annotations already cover the read-only safety profile, the description meets the baseline but adds limited extra 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.

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

The description is a single, front-loaded sentence with the tool's role followed by an enumerative list of inspection targets and a category tag. It contains no filler, though the phrase 'PDF Inspector' slightly duplicates the title annotation.

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

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

For a single-input, read-only inspection tool, the description is largely sufficient: it names the input type, the operation, and the main output categories. However, since there is no output schema and several overlapping PDF-analysis siblings exist, a brief note on where this tool fits among them would make it fully self-sufficient.

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

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

The only parameter, file, is fully documented in the schema as 'Input file (PDF)' with binary format. The description repeats the PDF context but contributes no additional constraints or format details. With 100% schema description coverage, a baseline score of 3 is appropriate.

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

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

The description identifies a specific function—deep inspection of a PDF—and enumerates concrete deliverables (page count, fonts, annotations, form fields, embedded files). It clearly places the tool in the analysis category, though it does not explicitly distinguish it from overlapping PDF-analysis siblings like pdf_file_info or pdf_page_count.

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

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

The [category: analyze] tag and the 'deep inspection' phrasing imply the tool is for broad read-only analysis of a PDF. However, the description provides no explicit guidance on when to use this tool instead of alternatives such as pdf_page_count, pdf_file_info, or analyze_metadata, and gives no when-not-to-use conditions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description usefully adds that the tool computes two specific readability scores, but it does not disclose operational details such as output structure, handling of short texts, or file-input behavior. 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.

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

The description is a single front-loaded sentence that immediately states what the tool does and which metrics it computes. It contains no filler and earns its place.

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

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

For a simple read-only tool with two well-documented parameters, the description covers the core behavior and compensates for the missing output schema by naming the metrics returned. The file-upload alternative is absent from the description but is already fully documented in the schema.

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

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

Schema description coverage is 100%, with both 'text' and 'file' parameters already documented in the input schema. The description adds little beyond naming the computed metrics, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb ('Calculate') and resource (readability metrics for a text), and even identifies the exact output metrics: Flesch Reading Ease and Flesch-Kincaid Grade Level. It is clear enough to distinguish from most siblings, though it does not explicitly call out a sibling tool for comparison.

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

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

The 'Readability Scorer' label and category imply it should be used when an agent needs readability statistics for a text. However, there is no explicit guidance about when to prefer this tool over related siblings like analyze_word_count or analyze_grammar_check, and no exclusions are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description need not repeat safety traits. The description adds the certificate-specific checks performed, but it does not disclose network behavior or possible failure modes beyond the schema's note about always using port 443.

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

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

The description is a single front-loaded sentence with no filler: it names the tool equivalently, states the operation, and lists the main result categories. Every part earns its place.

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

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

For a one-parameter read-only tool, the description is nearly complete: the schema covers the hostname parameter, annotations cover the safety profile, and the description names the expected output aspects. Since there is no output schema, a bit more detail about the exact return format could help, but it is not essential for selecting and invoking the tool.

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

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

Schema description coverage is 100%, and the schema's hostname parameter is already well-documented, including the 'not domain' naming note and port behavior. The tool description adds no parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: 'Check an SSL certificate for a hostname', and it lists the key result areas (expiry, issuer, validity, cipher suite). This makes the tool's function clear, though it does not explicitly differentiate itself from other analyze_* siblings.

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

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

The description provides no guidance on when to use this tool versus alternatives, and it names no sibling tools or exclusion conditions. The '[category: analyze]' tag implies a general domain but does not help an agent decide between this and other analysis tools.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Inspect' and 'Video Inspector'. The description adds value by specifying the exact behavioral scope—what properties are examined—without claiming any side effects. No contradictions with annotations exist.

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

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

The description is one tight sentence with a clear title prefix, an action verb, and a comma-separated list of outputs. Every word earns its place, and the key information is front-loaded.

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

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

For a read-only tool with one binary input and no output schema, the description sufficiently conveys what the tool returns by listing the inspected video properties. The agent can select and call the tool with confidence without missing critical context.

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

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

The schema has 100% description coverage for the single 'file' parameter, including supported formats. The tool description does not add additional parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Inspect') and resource ('a video') and enumerates the exact properties inspected: duration, resolution, frame rate, codec, audio tracks, and bitrate. This clearly distinguishes it from sibling tools like analyze_audio or analyze_file.

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

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

The description implies this tool is for inspecting video metadata and properties, so an agent can infer when it is appropriate to use. However, it does not explicitly state when to prefer it over related tools such as analyze_file, analyze_metadata, or media_extract_audio, nor does it provide exclusion criteria.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds that the tool handles text or .txt/.pdf/.docx uploads and computes several count-based metrics, which clarifies scope but adds little about side effects, processing limits, or return behavior beyond what annotations and schema already imply.

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

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

The description is a single efficient sentence with a clear em-dash lead-in, front-loading the core action and metrics. It is slightly redundant with the title and includes a category tag, but overall there is minimal waste.

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

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

For a low-complexity, read-only analysis tool, the description covers the resource type, supported formats, and what it counts. Since there is no output schema, it would help to explicitly state the return shape, but the metric enumeration makes the expected result reasonably inferable.

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

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

Schema description coverage is 100%, so the schema fully documents the 'text' and 'file' parameters. The description adds the list of computed metrics and the supported document formats, but these are mostly redundant with the schema and title; it does not deepen parameter understanding.

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

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

The description states a specific action ('Count') and resource (text or uploaded document), and enumerates the counted metrics. It distinguishes itself from siblings like analyze_word_frequency and analyze_readability by listing characters, sentences, paragraphs, and reading time, though it does not explicitly name an alternative tool.

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

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

No guidance is provided about when to use this tool versus alternatives such as analyze_word_frequency or analyze_grammar_check. The usage context is only implied by the tool name and metric list; there are no exclusions, prerequisites, or explicit routing instructions.

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

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

The readOnlyHint annotation already indicates this is a safe read-only operation, and the description adds no behavioral context beyond what the title implies. It does not disclose output format, supported document types, stopword handling, or limitations, so the description itself contributes little 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.

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

The description is only one sentence and is easy to scan. It does repeat the tool's title ('Word Frequency Analyzer') and appends a category tag, but these are minor and do not significantly reduce clarity.

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

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

Given that this is a simple read-only analysis tool with fully documented parameters, the description plus schema cover the basic inputs and purpose. However, there is no output schema and the description does not describe what the returned frequency distribution looks like, nor does it help distinguish this tool from close siblings. The definition is adequate but has clear gaps.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description adds no substantive parameter semantics beyond loosely referencing text or document files, which matches existing schema descriptions. A baseline of 3 is appropriate because the schema carries the full burden.

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

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

The description states a specific verb and resource: 'Analyse word frequency distribution in a text or document file.' It clearly identifies the tool's purpose, but it does not explicitly differentiate it from the closely related sibling analyze_word_count, so it falls slightly short of a 5.

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

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

The description gives no guidance on when to choose this tool over alternatives such as analyze_word_count or analyze_readability. It does not mention exclusions, preferred input scenarios, or trade-offs, so the agent must infer usage from the name and schema alone.

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

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

Annotations already declare readOnlyHint=true, and the description's 'Read the text' is fully consistent (no contradiction). The description adds genuine behavioral context beyond annotations: the business-plan gate, the max_chars truncation limit, and the exact input format scope.

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

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

Core information (purpose, formats, use cases) is front-loaded and each clause earns its place. Minor redundancy: 'Business plan only' is repeated by the trailing '[requires the business plan]' tag, and the opener echoes the title.

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

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

For a moderate-complexity file-ingestion tool with no output schema, the description covers purpose, formats, plan constraint, truncation limit, and the conversion workflow — enough for correct invocation. The main gap is the exact return shape (plain text vs. structured), which is left inferable.

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

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

With 100% schema coverage the baseline is 3, but the description adds value for the `file` parameter by specifying which formats are accepted — something the schema's generic 'The document to read' omits. It also reinforces the max_chars behavior ('Returns up to max_chars characters'), which helps the agent size the request correctly.

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

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

Specifies a concrete action (read/extract the text of the user's document), enumerates the supported formats (PDF, TXT, CSV, Markdown, JSON), and ties the tool to clear use cases (answer questions, summarize, use facts later). The chat-oriented framing distinguishes it from sibling extraction/conversion tools like pdf_to_text, and the Word-file exclusion clarifies scope.

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

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

Explicitly routes the Word-file edge case to convert_word_to_pdf before using this tool, which is strong when-to/not-to guidance. However, it stops there — it doesn't address alternatives for other scenarios (e.g., pure extraction via pdf_to_text, OCR for scanned PDFs via pdf_ocr), leaving some routing to inference.

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

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

Annotations only indicate readOnlyHint=false and destructiveHint=false, so they provide minimal behavioral signal. The description adds genuinely useful behavior: format recognition by filename extension or file signature, meaning misnamed uploads still work. This helps an agent predict behavior beyond 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.

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

The description is a single, efficient sentence that packs in the purpose, full input list, full output list, and a meaningful behavioral detail (signature detection). No filler or redundancy.

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

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

For a two-parameter conversion tool, the description plus schema covers everything needed: input formats, output formats, detection behavior, required parameters, and the `to` enum. No output schema exists, but the simple binary-output nature doesn't require further explanation.

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

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

Schema description coverage is 100%, so the schema already documents both `file` and `to` parameters. The description restates supported formats and detection behavior, but adds little beyond what the schema provides. Baseline 3 is appropriate.

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

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

Description states a specific verb ('Convert') and resource ('between archive formats'), with explicit input/output format lists. The format enumeration makes it clearly distinct from sibling conversion tools like convert_document or convert_video.

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

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

The description clearly establishes when to use this tool: whenever an archive file needs format conversion. It provides supported input and output formats, plus the note about signature-based detection. It doesn't explicitly name alternatives or state when not to use it, but the context is unambiguous.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), and the description adds real behavioral value: it returns a downloadable ZIP, applies auto-target per-file rules, and enforces tier-based file limits. The destructiveHint=false annotation is consistent with the description's implication that source files are not destroyed. No contradiction found.

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

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

Three tight sentences — purpose, target behavior, and tier limits — each earning its place, with the primary action front-loaded. The [category: convert] suffix is minor noise but does not detract.

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

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

For a batch tool with no output schema, the description covers the essential return shape ('download a ZIP of the results'), the failure model is covered in the schema's files parameter (_manifest.txt, skip-not-fatal), and tier limits are stated. Minor gaps remain — output filename behavior and mixed-type handling under a global target — but nothing that would prevent a correct invocation.

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

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

Schema coverage is 100%, so the baseline of 3 applies. The description reinforces the target parameter's dual mode (global format like 'pdf' vs per-extension override map) and adds auto-format examples, but this largely restates what the schema already documents for target and filenames. No meaningfully new parameter insight is added.

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

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

States a specific verb and resource: 'Convert many files in one request and download a ZIP of the results.' The batch + ZIP framing and concrete auto-target examples (docx→pdf, heic→jpg, mov→mp4) clearly distinguish it from single-file siblings like convert_file, convert_document, and convert_word_to_pdf.

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

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

The opening 'Convert many files in one request' clearly signals the batch use case, and the tier limits (5 free vs 50 Business) give an agent concrete eligibility checks before invoking. However, it does not explicitly name alternatives or state when NOT to use it (e.g., for a single conversion), so the when-not guidance is left implied.

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

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

The description goes well beyond the sparse annotations (readOnlyHint=false, destructiveHint=false). It discloses engine auto-picking from the conversion graph, magic-byte detection behavior, and the critical gotcha that text-based inputs require 'from' because they lack magic bytes. It also states the business-tier requirement.

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

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

The description is front-loaded with a clear purpose and example, and the magic-byte warning is valuable. However, 'Business tier only' and '[requires the business plan]' are redundant, and the 'category: convert' tag adds marginal value, so it is slightly less tight than it could be.

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

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

For a 3-parameter tool with full schema coverage, the description covers the essential semantics: step count, engine selection, input format detection, text-input warning, file size limit, and tier restriction. It does not describe return values or enumerate supported formats, but that is a minor gap given the richness of the schema and description.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining that each step's engine is auto-picked from the conversion graph, which clarifies the optional 'engine' field in the steps schema. It also reinforces the 'from' parameter's practical necessity for text-based inputs.

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

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

The description uses a specific verb and resource: 'Run a 1-5 step conversion pipeline in one job,' with a concrete example (docx → pdf → epub). This clearly distinguishes it from single-step converters like convert_file or convert_document among the siblings.

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

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

The description clearly indicates this is for multi-step conversion jobs ('1-5 step conversion pipeline in one job') and includes the business-tier restriction. However, it does not explicitly name alternatives or state 'use convert_file for a single conversion step,' so the when-not-to-use guidance is implied rather than explicit.

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

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

Annotations already indicate the operation is not read-only and not destructive, so the description adds little behavioral context beyond that. It does not state what happens to the input, how the output is returned, or any side effects. The format list is more about scope/parameters than behavior.

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

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

The description is a single, readable sentence that front-loads the tool's purpose and supported conversions. It contains minor redundancy ('vcf to excel' repeats vCard→XLSX, and 'Contact Converter —' echoes the title), but it is still compact and scannable.

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

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

The schema fully covers the parameters, and the description clarifies the conversion domain, making the tool invocable. However, there is no output schema and the description does not explain what the tool returns or how the converted file is delivered, which is a notable gap for a conversion tool.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description adds minimal parameter detail. The description repeats valid format pairs that are already documented in the 'to' parameter description, so it does not meaningfully enhance the schema.

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

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

The description clearly identifies the tool's specific verb ('Convert') and resource ('contact/calendar/email formats'), listing exact format pairs. This distinguishes it from the many generic convert_* siblings like convert_file and convert_document.

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

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

The description gives clear context on when to use the tool by enumerating supported conversions (vCard↔CSV, vCard→XLSX, ICS→JSON/CSV, MSG→EML, EML→PDF). It does not explicitly name alternatives or exclusions, but the domain is specific enough for an agent to route appropriately.

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

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

Adds useful behavioral facts beyond annotations: the result is returned as a downloadable file rather than an inline body, and inline text can substitute for a file upload. This is consistent with readOnlyHint=false and destructiveHint=false, since conversion creates an output artifact without destroying the input.

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

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

Three sentences, front-loaded with purpose and format list, then usage and output behavior. Minor redundancy exists: the 'Data Converter' prefix repeats the title/category, and 'upload the data file and pick a target format' restates required parameters, so it is not maximally tight.

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

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

For a 3-param tool with no output schema, the description adequately covers accepted inputs, output delivery as a downloadable file, and workflow chaining. Error cases and the 5MB limit are not explained in the description, but the size limit is in the schema and error behavior is not essential for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics by introducing an undocumented inline 'input' string alternative and confirming that 'from' is inferred when omitted. The only caveat is that 'input' is not present in the schema, which could confuse strict validation.

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

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

States a specific verb (convert), resource (data file), and enumerates the supported formats, which distinguishes it from document/media converters in the sibling list. It does not explicitly name or exclude overlapping siblings like convert_file or convert_text, so it falls just short of full differentiation.

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

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

Gives clear operational guidance: upload a file, pick a target format, or pass inline text, and notes the downloadable-file behavior for workflow chaining. It does not state when to prefer this tool over convert_file/convert_text/convert_batch, nor any when-not-to-use conditions, so usage is implied rather than explicit.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses significant behavioral detail: the conversion engines used (LibreOffice, pandoc), PDF text-layer extraction, the requirement to pass 'from', the same-category-only restriction for Office files, and the markdown-round-trip capabilities. It also names capability boundaries explicitly with 'Capability envelope', which goes well beyond what annotations express.

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

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

The description is long, but the tool is genuinely complex with many format families and conversion directions. It is front-loaded with the format list and uses clear separators plus a labeled 'Capability envelope' section. Some density could be eased, but every clause contributes operational meaning; no filler is present.

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

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

For a tool with three required parameters and no output schema, the description covers the important decision surface completely: accepted formats, conversion directions, unsupported cross-category cases, sibling fallbacks, and parameter semantics. An agent has enough context to select this tool and invoke it correctly without guessing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning on top of the schema: 'from' is emphasized as REQUIRED because extensionless uploads can't be sniffed, the file routing rule is clarified (extension first, 'from' as fallback), and the valid source-to-target combinations are summarized. This exceeds the bare schema definitions.

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

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

The description names a specific verb and resource: it converts documents across a broad set of formats, and it explicitly separates itself from convert_file (images/audio/video) and convert_data. It details both the input and output directions, so an agent can distinguish it from siblings without opening the schema.

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

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

The description gives explicit routing guidance: 'For images/audio/video use convert_file; for data-text transforms use convert_data.' It also states when to prefer dedicated PDF tools (pdf_to_word, pdf_to_excel, etc.) and enumerates unsupported conversion categories. This is strong when-to-use / when-not-to-use guidance.

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

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

Beyond the minimal annotations, the description discloses that DRM-protected books always fail and that pdf→epub reflows fixed pages causing quality to vary with layout complexity. It does not contradict annotations and adds meaningful runtime behavior, though it doesn't describe the return artifact or other side effects.

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

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

The description is dense and front-loaded with the operation, formats, recommendations, and caveats. The redundant 'eBook Converter —' prefix and trailing '[category: convert]' tag add minor noise, but the core content is efficiently organized.

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

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

For a 3-parameter conversion tool with full schema descriptions and no output schema, the description covers the key decisions: direction, quality caveat, DRM limitation, and routing. The main residual gap is the undocumented meaning of to=pdf and the lack of any statement about the returned artifact, which keeps it just below a 5.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value by constraining valid source→target directions and identifying epub→pdf as outside this tool's scope. Slight ambiguity remains because the to-schema includes pdf while the description only names epub/mobi/azw3 as targets, but the core format semantics are well-enriched.

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

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

States the core operation with a specific verb and resource: 'Convert ebooks between formats with calibre', and enumerates the supported direction pairs (mobi/azw3/fb2/lit/pdf → EPUB, epub → mobi/azw3). It also differentiates from convert_document by explicitly routing epub→pdf elsewhere, so an agent can identify the right tool without inspecting schemas.

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

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

Gives concrete selection criteria: EPUB is recommended for modern Kindles/send-to-device, DRM-protected books cannot be converted, and epub→pdf should go to convert_document (LibreOffice). This is an explicit when-to-use and when-not-to-use statement versus named alternatives.

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

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

Beyond the minimal annotations (readOnlyHint=false, destructiveHint=false), the description discloses substantial behavior: which formats are input-only (heic/svg/psd), that alac is delivered as .m4a, that legacy video formats are re-encoded to mp4, audio-extraction paths, and subtitle conversions. This adds real behavioral context the annotations cannot convey.

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

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

The content is dense and front-loaded with the core purpose, but the entire payload is one enormous run-on sentence crammed with slashes and parentheticals. Every item arguably earns its place, yet the lack of structural breaks (bullets or clauses) makes the format matrix harder to parse than it should be.

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

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

For a 3-parameter tool with no output schema and no enums, the description covers the supported domain remarkably well: all conversion families, input-only formats, output container caveats, and sibling routing. The main gap is that it never states what the response looks like (the converted file payload), which matters more given there is no output schema.

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

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

Schema coverage is 100% and each parameter has a description, so baseline is 3. The description adds value beyond the schema by effectively enumerating valid values for `to`/`from` (the full format lists) and clarifying pairings (e.g., image→image, audio→audio), which the schema does not constrain with enums. It supplements but does not fully duplicate the schema.

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

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

The description states a specific verb and resource ('Convert a file between formats') and enumerates the exact conversion matrix. It explicitly distinguishes itself from siblings by naming convert_document, convert_archive, and convert_data as the homes for Office, archive, and data conversions, so an agent can tell this tool apart without opening schemas.

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

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

The description explicitly routes non-matching workloads to named alternatives ('Office/document conversions ... live in convert_document; archives in convert_archive; data formats in convert_data') and flags the 'Business gate on some edges' for video conversions. This is explicit when-to-use vs when-not-to-use guidance.

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

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

The description goes well beyond the sparse annotations by disclosing that lossy conversions are reported in X-Conversion-Notes rather than silently dropped, and that strict=true changes behavior to refusal. It also lists which data features survive, adding meaningful operational insight.

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

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

The description is dense but efficiently organized, leading with purpose, then preservation guarantees, then error-handling behavior. Minor stylistic flourishes like 'all survive the trip' do not waste space and reinforce user expectations.

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

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

For a four-parameter converter with no output schema, the description covers supported formats, preservation details, and lossy-conversion handling. It does not explicitly describe the response envelope, but the operation and schema make the returned converted file predictable.

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

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

Schema coverage is 100%, with each parameter already described including the gpx→gpx 400 rule and strict behavior. The description's mention of strict=true merely echoes the schema, so it adds little over the structured input.

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

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

States a specific verb ('Convert') plus the exact resource set (GPX, KML, KMZ, GeoJSON), and names the GPS/mapping ecosystem. This clearly distinguishes it from sibling convert_* tools like convert_document or convert_video without needing to open schemas.

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

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

The description gives clear context by defining the supported geospatial formats and typical use cases (Garmin, Strava, Google Earth, GIS). It does not explicitly name alternative tools or when not to use this one, but the domain specificity makes selection straightforward.

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

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

The annotations already signal that this is not read-only and not destructive; the description adds that the tool takes one or more images and produces a PDF, which is useful. However, it does not disclose output format details, whether the images are merged in order, side effects, or any limits, so the behavioral context is minimal beyond the basic operation.

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

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

The description is short and front-loaded, with the core action stated immediately. The leading 'JPG to PDF' and the '[category: convert]' tag are somewhat redundant given the tool name and sibling context, but the overall structure is still efficient and scannable.

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

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

For a simple one-parameter conversion tool, the description covers the input and output at a high level. However, there is no output schema and no guidance about how the resulting PDF is returned or how this differs from pdf_images_to_pdf, leaving some ambiguity in a large sibling toolset.

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

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

The schema already describes the only parameter as 'Input files (JPG, PNG)' with 100% coverage, so the schema carries the parameter meaning. The description adds the phrase 'one or more,' but this is already implied by the array type, so it provides little additional semantic value.

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

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

The description clearly states a specific verb ('Convert') and resource ('one or more JPG/PNG images to a PDF document'), so an agent can understand the core function. However, it does not distinguish itself from the closely related sibling pdf_images_to_pdf, and the leading 'JPG to PDF' essentially restates the tool name.

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

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

The description implies the tool should be used when JPG/PNG images need to be converted to a PDF, and it mentions the acceptable input formats. It does not explicitly say when to prefer this tool over alternatives like pdf_images_to_pdf, convert_file, or convert_batch, so the usage guidance is mostly implicit.

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

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

Discloses substantial behavior beyond the sparse annotations: type preservation in both directions with concrete examples (numbers stay numeric, blanks become true nulls, '01924' keeps its leading zero), and explicit handling of nested/repeated columns as reported rather than silently flattened. No contradiction with readOnlyHint=false or destructiveHint=false.

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

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

Three sentences with no waste: scope, behavioral guarantees with concrete examples, then the schema-shape constraint. Purpose is front-loaded before caveats, and the 'Parquet Converter —' opener anchors the reader before the action verb.

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

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

For a 4-parameter bidirectional converter with a fully covered schema, the definition is nearly complete: purpose, type behavior, and schema limitations are all addressed. The only gap is that the return value is never described (file download, link, etc.), which matters more given there is no output schema.

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

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

Schema description coverage is 100%, so the baseline of 3 applies; the schema already documents to, file, from, and sheet thoroughly, including the jsonl alias and the convert_data routing note. The description's type-preservation examples add background context for format choice but do not map to any specific parameter's usage.

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

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

States a specific action and resource — converts Apache Parquet to/from CSV, TSV, JSON, NDJSON, and Excel — with 'and back' making the bidirectional scope explicit. The flat-schema-only constraint further distinguishes it from generic table converters, so an agent can tell it apart from the many convert_* siblings without opening the schema.

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

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

The format list clearly defines when to use it (any conversion with Parquet on one side), and 'flat schemas only' is a stated when-not condition. It never names alternatives in the description itself, though the schema's to-parameter description compensates by routing table→table pairs to convert_data; full coverage of siblings like convert_file and convert_batch is absent.

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

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

The description discloses non-obvious output behavior: CSV produces one file per table and zips when there are several, JSON keys objects by table, and Excel always creates a single workbook with one worksheet per table. This goes well beyond the annotations, which only indicate readOnlyHint=false and destructiveHint=false.

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

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

The description is front-loaded with the core purpose, then expands into output-format specifics and the optional parameter in a compact, well-organized way. Every sentence earns its place, with only a minor category tag as light supplemental noise.

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

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

There is no output schema, so the description appropriately explains what the caller should expect from each target format, including multi-table behaviors. It is complete enough for the tool's moderate complexity, though it does not mention delivery mechanics or error conditions.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters well. The description adds some reinforcement, such as explaining that passing 'table' exports a single table, but it does not significantly extend the schema's parameter semantics.

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

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

The description opens with a specific verb and resource: 'Export a SQLite database (.db/.sqlite) to CSV, JSON or Excel.' This clearly identifies the tool's function and scope, and the format list differentiates it from generic sibling tools like convert_file or convert_data.

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

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

The description gives clear context for when to use the tool — whenever a SQLite database needs converting to CSV, JSON, or Excel. It also explains usage trade-offs like CSV being zipped with multiple tables and when to pass the optional 'table' parameter, though it does not explicitly compare against alternative conversion tools.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false. The description adds a helpful disambiguation warning, but does not clarify whether the operation is a pure in-memory conversion with no side effects or whether it writes output somewhere. Given readOnlyHint=false, the agent is left uncertain about side-effect behavior, though destructiveHint=false rules out destructive actions.

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

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

Two efficient sentences deliver the core purpose, supported conversions, and critical parameter notes. The information is front-loaded and every clause earns its place. The trailing [category: convert] tag is minor metadata and does not add noise.

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

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

For a simple three-parameter converter with full schema coverage, the description covers the essential invocation details and supported pairs. It could be more complete by explicitly stating the return value (converted text in target format) and clarifying when to use alternative convert tools, but the current level is sufficient for correct basic invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly confirming the parameter names ('text', 'from', 'to') and warning that there is no 'conversion_type' field — a highly useful guard against a common hallucinated parameter. It also confirms that encode/decode operations ride in 'from', reinforcing the schema.

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

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

The description uses a specific verb (Convert) and resource (text/data formats), then enumerates the supported conversions (Markdown↔HTML, CSV↔JSON, JSON↔XML/YAML, Base64/URL encode-decode). This makes the tool's purpose unmistakable and distinguishes it from file-oriented siblings like convert_file or convert_archive by explicitly limiting scope to text/data formats.

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

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

The description implies usage through the supported format list and required parameters, but never explicitly states when to prefer this tool over the many similar convert_* siblings (e.g., convert_data, convert_document, convert_file). It gives no when-not-to-use guidance or alternative routing, so an agent must infer the boundary from the format list alone.

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

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

The description communicates the core conversion behavior and category scope but adds little behavioral detail beyond the annotations. Important caveats such as 'temperature units aren't validated — a typo returns garbage' and 'data units are binary' live in the schema rather than the description. There is no contradiction with readOnlyHint=false or destructiveHint=false.

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

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

The description is a single, front-loaded sentence with no filler beyond the redundant 'Unit Converter —' prefix, which repeats the title. Overall it is compact and scannable.

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

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

For a simple four-parameter conversion tool with fully described schema fields, the description supplies enough scope to select the tool correctly. The only minor gap is that no output format is described, though the expected result of a unit conversion is fairly predictable.

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

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

Schema description coverage is 100%, and the schema thoroughly documents value, from, to, and category, including snake_case naming, binary data units, and temperature restrictions. The description only adds high-level category context, so it does not meaningfully extend the schema's parameter guidance.

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

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

The description states a specific operation, 'Convert between units of measurement', and enumerates the supported categories: length, weight, temperature, volume, area, speed, time, and data sizes. This clearly distinguishes it from the many convert_file/convert_document/convert_data siblings.

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

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

The description clearly frames when to use the tool: whenever a unit conversion between named measurement categories is needed. It does not explicitly name alternatives or exclusions, but no sibling tool appears to cover unit conversion, so the context is sufficient.

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

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

The description discloses significant behavior beyond annotations: the SSRF-guarded fetcher, server-side asset fetching and inlining, offline rendering, and the static-rendering limitation. This is exactly the kind of behavioral context that helps an agent predict side effects and failure modes.

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

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

The description is compact but information-dense: it front-loads the core purpose, then covers mechanism, security, and limitations in a few sentences. Every clause adds value, and there is no redundant filler.

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

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

For a simple one-parameter conversion tool, the description is complete enough: it explains what it converts, how it fetches and renders, the key security trait, and the main limitation. No output schema exists, but the output is clearly implied by 'to PDF', and nothing essential is missing.

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

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

The input schema already fully documents the single 'url' parameter with a clear description, so the baseline is 3. The description adds a small amount of extra meaning by specifying that the URL should be passed as a JSON-body property, but this is marginal beyond the schema.

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

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

The description names a specific verb (Convert), a specific resource (a live web page/URL), and a concrete output (PDF). It also distinguishes itself from HTML-to-PDF or file-conversion siblings by emphasizing 'live web page' and 'server-side fetcher'.

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

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

The description gives clear context for when the tool is appropriate: converting a live URL to PDF. It also provides an important when-not signal by stating JavaScript is not executed, so SPAs may render sparsely. It stops short of naming an alternative tool explicitly, which keeps it just below a 5.

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

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

Annotations already cover the read-only/destructive profile, and the description adds useful behavioral context: free-tier format/resolution restrictions, AV1 Business gating, and legacy-to-mp4 conversion behavior. It doesn't discuss output destination or original-file preservation, but destructiveHint=false plus the conversion framing makes that omission acceptable.

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

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

The description is front-loaded with the purpose and trigger, then moves to supported formats, presets, legacy coverage, and tier limits. A few words are redundant ('Video Converter—' repeats the name), but every sentence carries distinct, useful information.

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

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

Together with the schema, the description covers the main selection and invocation concerns: what triggers the tool, which formats/codecs/resolutions are supported, and which require Business. There is no output schema, so a brief statement about the return value would have made it complete, but the conversion outcome is predictable from the target format.

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

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

Schema description coverage is 100% and the parameter descriptions are rich (preset precedence, GIF palette optimization, CRF vs ABR). The tool description only summarizes 'codec/resolution/bitrate control', adding no detail beyond the schema, so the baseline 3 applies.

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

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

The description opens with a specific trigger—'Convert a video so it PLAYS or IMPORTS where it currently will not'—and names concrete source/target formats, presets, and legacy-format support. This clearly identifies the tool as the compatibility-focused video converter and separates it from the many convert_*/media_* siblings.

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

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

It gives a clear use case: when a player, editor, website, or social platform refuses a recording. It also states free-tier limitations and Business-only formats, implicitly telling an agent when the tool is not usable on a given plan. It does not explicitly name alternatives like media_compress_video or media_trim_video, so it stops short of a 5.

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

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

Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds the LibreOffice engine and accepted formats beyond that. It does not disclose output behavior (returned file vs. link) or limitations like size or .doc fidelity, though the simple schema lowers the burden.

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

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

The description is a single front-loaded sentence that states the action immediately. The '[category: convert]' tag is mild redundancy given the convert_ prefix, but it adds no significant bloat.

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

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

For a one-parameter converter with no output schema, the description covers the input side adequately. It does not state what the tool returns after conversion, and given dozens of convert siblings, a routing hint toward/away from convert_document or pdf_to_word would improve completeness.

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

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

Schema coverage is 100% and the single 'file' parameter is described as 'Input file (DOCX, DOC)' in the schema itself. The description repeats the format scope but adds no new parameter-level meaning, so the high-coverage baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Convert a Word document (.docx, .doc) to PDF using LibreOffice.' The explicit format coverage (.docx/.doc) and target output (PDF) distinguish it from the many convert_* and pdf_* siblings without needing to open the schema.

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

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

Usage is implied by the name and format details — an agent can infer 'when a Word file needs PDF output.' However, no alternatives or exclusions are mentioned, which is a gap given the broad sibling list includes convert_document, convert_file, convert_batch, and pdf_to_word (the reverse operation).

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

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

The description supplements the readOnlyHint annotation by explaining the underlying mechanism (vision model) and gives concrete behavioral examples such as detecting blurriness or visible text. It also discloses the business plan access requirement. 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.

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

The description is short, front-loaded, and easy to parse. The only minor redundancy is that the business plan requirement appears both in prose and as bracketed metadata, which slightly weakens editorial precision.

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

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

For a simple read-only image description tool, the description covers the tool's purpose, mechanism, access restriction, and typical use cases. It does not specify the exact output format, but 'answer a question' adequately implies a text response.

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

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

The input schema already fully documents both parameters, including that question is optional and defaults to a concise description. The description adds illustrative examples of what the question can cover, but those are helpful examples rather than essential semantic details.

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

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

The description clearly states the action: look at an image with a vision model and answer a question about it. It gives concrete examples of what the tool can report (contents, blurriness, usability, visible text). However, it does not explicitly distinguish itself from overlapping siblings like analyze_image_quality or photo_to_text.

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

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

The use case is implied: use when you need a natural-language answer or description of an image's contents. There is no explicit when-to-use versus alternatives guidance, and the only explicit constraint is the business plan requirement.

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

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

Annotations only indicate readOnlyHint=false and openWorldHint=true. The description adds meaningful behavioral constraints: the recipient is always the current user, the tool cannot email anyone else, and it cannot send custom or user-authored content. This goes beyond the annotation data and prevents misuse.

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

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

The description is compact and front-loaded, stating the core action in the first sentence and then adding important restrictions and usage guidance. Every sentence earns its place with no redundancy.

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

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

For a simple utility tool with three well-documented parameters and no output schema, the description provides all necessary context: what it does, who can receive the email, what content can be included, and when to use it. Nothing critical is missing.

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

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

Schema description coverage is 100%, and each parameter already has a clear description. The tool description adds general context about the recipient and email restrictions but does not add new parameter-level meaning beyond what the schema provides. A baseline of 3 is appropriate.

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

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

The description uses a specific verb+resource: 'Email a finished file to the signed-in user's OWN email address.' It clearly states the tool's scope and its key limitation (cannot email anyone else), so an agent can distinguish it from the broader utility and sharing toolset.

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

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

The description explicitly says 'Use ONLY when the user explicitly asks to have a result emailed to them.' This gives a clear, actionable condition for when the tool should be selected and rules out using it for emailing other people or sending custom content.

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

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

Annotations already establish that the tool is not read-only and not destructive. The description adds useful behavior context: the Pro+ ed25519 audit trail and the free-tier limit of 3 signed documents per month. It does not state whether the original file is overwritten or how quota exhaustion is handled, but the annotation baseline lowers the burden.

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

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

The description is compact and front-loaded with the core action, followed by quota and category context. The 'PDF E-Signature' opener is slightly redundant with the title, and the category tag adds mild noise, but every sentence contributes useful information.

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

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

With no output schema, the description does not explain what the tool returns (e.g., signed PDF bytes or a file reference) or how quota-exceeded attempts behave. It also leaves unclear whether the input PDF is modified in place or a new file is produced. However, the input schema is fully covered and the quota/audit context is present, making the core invocation mostly understandable.

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

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

The schema already documents the two parameters and the fields JSON structure at 100% coverage. The description adds meaning by enumerating the expected field types (signature, initial, date, text) and indicating draw-or-type signature input, which clarifies plausible values for 'type' and 'image_b64'. It does not document coordinate units or other per-field constraints, so it is not a 5.

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

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

The description uses a concrete verb ('Place') and names the PDF as the target, listing the supported field types (signature, initial, date, text) and signature input modes (draw or type). It is clearly distinct from PDF conversion and analysis tools, though it does not explicitly differentiate itself from the sibling esign_prepare, so it stops short of a 5.

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

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

There is no explicit guidance about when to use this tool versus alternatives such as esign_prepare or other PDF tools. The free-tier cap is a constraint, not a usage rule, and no exclusion conditions or alternative recommendations are provided.

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

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

The description clearly states what the tool returns, which is helpful. However, annotations mark readOnlyHint as false, implying possible side effects, but the description does not disclose any state changes, storage, or session behavior. It avoids contradicting the annotations but leaves the side-effect profile ambiguous.

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

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

A single, front-loaded sentence states the action, the resource, the output, and the purpose. The trailing [category: sign] is compact metadata. There is no filler or repetition.

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

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

With one parameter, no output schema, and a simple purpose, the description covers the essential return values and context. It does not specify the exact output format or failure behavior, but for this low-complexity tool the description is largely sufficient for an agent to select and invoke it.

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

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

Schema description coverage is 100% for the only parameter, file, which is already documented as 'Input file (PDF).' The description adds nothing about the parameter beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Return page count and per-page point dimensions for a PDF.' It also explains the purpose—positioning signature fields—which clearly distinguishes this from generic PDF tools like pdf_page_count or pdf_file_info and from the sibling esign_place.

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

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

The phrase 'so signature fields can be positioned by the editor' gives clear context for when this tool should be used: in an e-sign workflow before placing signatures. It does not explicitly mention when not to use it or name alternative siblings, but the intended context is apparent.

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

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

Annotations already indicate this is not read-only and not destructive, and the description adds the behavioral mode dependency (text vs. image input). It does not disclose return format, error behavior, or side effects beyond conversion, but for a simple generator the provided context is acceptable.

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

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

The description is a single efficient sentence that front-loads the main purpose and then adds the key mode distinction. The lead-in 'ASCII Art Generator' is slightly redundant with the tool name, but the overall structure is tight and scannable.

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

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

For a tool with moderate complexity, the description plus a fully documented schema covers the essential calling requirements: modes, required inputs, default behavior, and constraints. There is no output schema, but the tool's output is implied by the purpose and the schema fills the remaining operational details.

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

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

Schema description coverage is 100%, so the schema fully documents all five parameters. The description's mention of mode/text/file requirements adds no new meaning beyond what the schema already states, which keeps this at the baseline of 3.

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

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

The description states a specific verb and resource — 'Convert text or an image to ASCII art' — which clearly identifies what the tool does. The mode note adds precision, but it does not explicitly compare against siblings like generate_qr_code or generate_barcode, so it stops short of full differentiation.

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

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

The description gives concrete usage conditions for the two modes: text mode requires 'text' and image mode requires 'file'. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving sibling routing largely to the agent's inference.

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

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

Annotations already mark the tool as generative and non-destructive, and the description adds the key output trait: the result is a PNG image. For a low-risk generation tool this covers the main behavioral contract, though it does not explain how the image is returned.

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

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

The key action and output format are front-loaded in a short, readable sentence, with schema details left to the structured fields. The opening 'Barcode Generator' duplicates the title and the [category: generate] tag is marginal, so it is not a perfect 5.

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

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

With all parameters described in the schema and the description naming the PNG output, an agent has enough information to invoke this tool correctly for a simple generation task. The main missing piece is guidance for QR-only requests, which could otherwise be routed to generate_qr_code.

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

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

The input schema documents all three parameters, including defaults, bounds, and the type enum, so the baseline applies. The description adds only a few human-readable symbology examples without contributing new constraints beyond the schema.

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

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

The description clearly states the action (generate a barcode), the resource, and the output format (PNG), and gives example symbologies that signal scope. It does not explicitly distinguish itself from the closely related sibling generate_qr_code, so it stops short of a 5.

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

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

There is no guidance about when to use this tool instead of alternatives such as generate_qr_code, nor does it mention that the schema supports QR. The only usage hint is the generic [category: generate] tag, which is not sufficient for an agent to route between related generators.

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

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

Annotations only provide readOnlyHint=false and destructiveHint=false, so the 'Generate' action and PDF/PNG output add modest behavioral context. However, the description does not disclose quirks like the silent PDF fallback for invalid format values or Latin-1 rendering limits; those details are only visible in parameter descriptions.

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

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

The description is a single front-loaded sentence that conveys the core action, inputs, and output formats. The 'Business Card Generator' title-like prefix is mildly redundant with the tool name, but it does not detract meaningfully from clarity.

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

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

With 100% schema coverage and no close sibling ambiguity, the description covers the essentials: what is generated, from what data, and in which formats. It does not explicitly describe the return artifact type, but 'printable business card (PDF or PNG)' sufficiently implies a file output for this class of tool.

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

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

Schema description coverage is 100%, and the parameter descriptions already carry rich semantics such as 'no leading #', 'fullName' not 'name', and empty-string line omission. The tool description only lists general fields and adds no parameter meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb ('Generate'), a specific resource ('business card'), and the output formats (PDF or PNG), sourced from name, job title, company, and contact details. The resource is distinct enough to differentiate it from other generate_* siblings.

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

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

The description implies the tool should be used when a business card is needed, but it does not explicitly state when to prefer this tool over alternatives or any exclusions. Since no sibling is functionally close, the context is adequate though not explicit.

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

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

Annotations are minimal (all-false hints: not read-only, not destructive, closed-world), and the description adds the output format (PDF/PNG) and printability, which is consistent with a file-generation tool. The genuinely valuable behavioral disclosures — template is a no-op, unknown enum values silently fall back, issuerName empty hides the WHOLE issuer block, invalid orientation renders landscape — live in the schema descriptions, not the description. 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.

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

The core description is one efficient, scannable sentence with the resource and output formats front-loaded. The 'Certificate Generator —' prefix is redundant with the tool name and title, and the '[category: generate]' suffix adds marginal value, but there is no bloat or repetition beyond that.

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

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

For a 10-parameter tool with no output schema, the description alone is thin, but the schema descriptions are so thorough that invocation is well-supported: every enum has fallback documentation, every dependency is spelled out, and the required field is flagged with a naming caution. The gaps are tool-selection context and explicit return semantics (file versus link/path), which neither the description nor an output schema covers.

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

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

Schema description coverage is 100%, so the baseline is 3 per the rubric. The schema descriptions are exemplary: they document defaults, silent fallbacks ('Any other value silently returns the PDF'), field-name gotchas ('Field name is "certTitle" — not "title"'), and conditional rendering (issuerTitle only when issuerName is set). The description itself contributes zero parameter semantics, but the schema fully compensates.

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

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

The description states a specific verb and resource: 'Generate a printable certificate of achievement or completion as PDF or PNG.' This clearly distinguishes it from most generate_* siblings (barcode, invoice, QR code, etc.). However, the 'Certificate Generator —' prefix merely restates the tool name/title, and the differentiation from sibling document generators like generate_business_card or generate_invoice is implicit rather than explicit.

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

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

The use case is implied by the wording 'certificate of achievement or completion' — an agent can infer it's for issuing formal certificates. But the description offers no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as generate_invoice or generate_business_card for other document types. Tool-selection context is left entirely to inference.

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

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

Annotations carry very little (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description must disclose behavior. It does state the output composition (ico + png sizes) and the transformation inputs (source image, rounded corners), consistent with annotations. However, it doesn't disclose the return format, how outputs are delivered (download? URLs? zip?), or which PNG sizes are produced, and there is no output schema to compensate.

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

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

The core action is front-loaded in the first sentence, and the second sentence earns its place by explaining the real-world value prop (prevents blank-page symbol). The '[category: generate]' tag is mildly redundant since the name already signals the category, but it's a minor cost. Overall tight and well-ordered.

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

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

The invocation contract is fully covered: one required source file documented in the schema, two optional parameters with defaults and bounds. The main gap is the tool's return value — there is no output schema and the description never states what format the generated favicon set comes back in, which an agent needs to relay results to the user. Adequate for invocation, incomplete for post-call handling.

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

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

Schema description coverage is 100% — file, includeIco, and borderRadius each have clear descriptions with constraints and defaults already in the schema. The description only echoes 'optional rounded corners' and the 'ico + png' output, adding no meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource construction: 'Generate a favicon set (ico + png sizes) from a source image, with optional rounded corners.' It identifies the artifact, the input, and the transformation applied, and the favicon explanation (browser tab, bookmark, home screen) clearly distinguishes it from sibling generate_* tools like generate_barcode, generate_qr_code, and generate_placeholder_image.

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

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

The description gives clear context for when the tool is needed — it explains what a favicon is, where it appears (tab, bookmark, phone home screen), and the symptom of not having one (blank page symbol). This grounds the agent in the website-favicon scenario without ambiguity. It stops short of explicitly naming alternatives or stating when-not-to-use, hence 4 rather than 5.

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

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

The description discloses key behavior beyond the sparse annotations: it always returns all four hash types, there is no algorithm selection, and bcrypt is not supported. It does not describe the exact output format, but the core behavioral expectations are clear.

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

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

The description is compact and well-ordered: purpose and supported algorithms come first, followed by behavioral constraints. Every sentence carries useful information with no padding.

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

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

For a simple two-parameter tool, the description covers accepted inputs, supported algorithms, and key constraints. However, the unresolved text-versus-file requirement conflict and the lack of any output shape detail leave enough ambiguity that an agent may struggle to invoke the tool correctly on file-only inputs.

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

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

The schema already documents both parameters, so the baseline is 3, but the description fails to clarify a real ambiguity: the schema marks 'text' as required while both the tool description and the text parameter's own description imply 'text' can be omitted when 'file' is provided. An agent cannot confidently determine whether file-only invocation is valid.

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

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

The description states a specific verb and resource: computing MD5, SHA-1, SHA-256, and SHA-512 hashes of text or an uploaded file. It also distinguishes itself by explicitly noting that it always returns all four hashes and does not support algorithm selection or bcrypt.

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

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

The description clearly indicates what inputs the tool accepts (text or file) and gives an exclusion: no algorithm selection and no bcrypt. However, it does not name an alternative tool or explicitly state when a user should choose a different tool.

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

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

Annotations already signal readOnlyHint=false and destructiveHint=false; the description adds that the tool produces a PDF and expects JSON input. It doesn't disclose return/delivery behavior, auth requirements, or side effects, but the core output type is stated and no contradiction with annotations exists.

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

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

The description is short and front-loads the main action, with no filler beyond the useful '[category: generate]' tag. It loses one point because 'Invoice Generator —' mostly duplicates the annotation title, creating slight redundancy before the actual verb.

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

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

This is a 15-parameter tool with no output schema, but the schema descriptions cover required fields, defaults, formatting quirks, and conditional rendering, making the input side very complete. The description supplies the key JSON/camelCase framing and output type; only the exact return/delivery mechanism is left underspecified.

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

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

Schema coverage is 100% and the individual parameter descriptions are unusually rich, so the baseline is 3. The description adds meaningful invocation-level semantics—JSON body, camelCase fields, not form fields—and groups the inputs into line items, client details, and company info, which goes beyond what the schema alone provides.

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

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

The description opens with a specific verb and resource: 'Generate a professional PDF invoice' from line items, client details, and company info. This makes the tool immediately distinguishable from sibling generate_* tools such as generate_certificate or generate_barcode without requiring schema inspection.

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

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

It clearly sets the invocation context by stating the tool takes a JSON body with camelCase fields, not form fields, which is a critical calling-convention detail. It doesn't explicitly name alternatives or when-not-to-use, but among the sibling list it is the only invoice generator, so the intended usage context is clear.

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

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

Annotations provide little safety context (readOnlyHint: false, destructiveHint: false), so the description carries the burden. It adds that generation is driven by word or paragraph count, but it does not disclose whether the output is plain text, whether it is returned directly to the caller, or whether any file is created. For a simple generator this is a modest but acceptable transparency level.

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

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

The description is a single front-loaded clause followed by a category tag, with no filler or redundant explanation. It is appropriately sized for a simple tool, even though it omits one supported mode, which is an accuracy issue rather than a conciseness issue.

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

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

For a simple generator with fully documented parameters and no output schema, the description covers the core purpose and main modes. Missing details such as exact return format or whether output is a file are not clearly stated, but 'placeholder text' strongly implies the result is returned text, making the definition mostly complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema; it reinforces the concept of count-based generation but does not explain parameter interplay or the startLorem option, which the schema already documents adequately.

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

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

The description clearly identifies the tool as generating lorem ipsum placeholder text and mentions word/paragraph count modes, so the resource and action are specific. However, it does not explicitly differentiate from sibling generators such as generate_placeholder_image, and it omits the 'sentences' mode that the schema supports, making it slightly incomplete.

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

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

The description gives no guidance on when to use this tool versus related alternatives like generate_placeholder_image or other text-generating tools. There are no when/when-not conditions or explicit exclusions; the intended usage must be inferred from the resource name and context.

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

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

Annotations establish readOnlyHint=false and destructiveHint=false, and the description's 'Generate' is consistent with those hints — no contradiction. The description adds genuine value with the 'cryptographically secure' trait, signaling to the agent that this is a CSPRNG-based generator suitable for real credentials rather than a toy. It does not surface edge-case behaviors like the all-flags-false fallback or length clamping, though those are already documented in the parameter schema.

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

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

A single tight sentence front-loads the tool name and states the action, security property, and configurability with zero filler. The trailing '[category: generate]' tag is small and aids organization without adding noise.

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

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

For a tool with 7 fully-documented parameters and clear non-destructive annotations, the description gives an agent everything needed to decide to invoke it correctly. The only gap is the absence of a stated return shape (single string vs. array when count > 1), which is a platform gap given no output schema, and is largely self-evident for a password generator.

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

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

Schema description coverage is 100%, with every parameter fully explained in the input schema (including subtle behaviors like 'all four false/omitted = every class enabled' and clamping of length values). The description's high-level mention of 'configurable length and character sets' adds no meaning beyond that exhaustive coverage, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'Generate a cryptographically secure random password with configurable length and character sets.' The combination of 'Password Generator' title and 'password' scoping cleanly distinguishes it from the many sibling generate_* tools (generate_barcode, generate_qr_code, generate_hash, generate_invoice, etc.), which all have clearly different outputs.

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

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

Usage context is implied by the purpose statement — an agent can infer this tool is for producing secure random passwords whenever credentials are needed. However, there is no explicit when-to-use/when-not-to-use guidance and no alternative tools are named (e.g., no mention that generate_hash serves hashing rather than password generation), so the guidance stops at implication.

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

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

Annotations only provide false hints for read-only/destructive behavior, and the description adds little behavioral context. It doesn't state how the generated image is returned (binary, URL, saved file), whether any server-side storage occurs, or what side effects, if any, exist. The schema mentions response MIME, but the tool description itself is thin on behavior.

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

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

The description is a single, front-loaded sentence that names the action, the resource, and the main customization options, followed by a useful [category: generate] tag. There is no filler or redundant explanation.

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

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

The parameter schema is rich and covers the input side well, but there is no output schema and the description does not explain what the tool returns or how the generated image is delivered. For a tool with six optional parameters and no required inputs, an agent would benefit from knowing the response shape or storage behavior.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's phrases like 'any dimension' and 'custom background colour and label text' broadly map to parameters, but they don't add meaning beyond the schema's already detailed per-parameter descriptions, which include defaults, clamping behavior, and exact field names.

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

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

The description states a specific verb ('Generate') and a specific resource ('placeholder image'), and further clarifies the key options: any dimension, custom background colour, and label text. This clearly distinguishes it from sibling tools like generate_qr_code, generate_barcode, or photo_resize.

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

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

The description gives a clear context for use—creating placeholder images with custom dimensions, colors, and text—but it does not explicitly say when not to use it or mention alternative tools. Usage is implied by the resource type rather than explicitly routed.

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

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

Annotations are neutral (all flags false), so the description carries the behavioral burden. It adds the key trait that output is a PNG image and that content may be URL, text, or vCard. It does not disclose return mechanics (file path vs. binary vs. base64), but for a simple generate tool the disclosed traits are the most relevant. 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.

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

The substantive sentence is tight and front-loaded: verb, resource, input types, and output format all in one line. Minor redundancy exists — 'QR Code Generator' repeats the title, and '[category: generate]' restates the name prefix — but neither is costly.

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

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

For a low-complexity tool with 3 params, 100% schema coverage, and a clear one-sentence description, this is nearly complete. The remaining gaps are return-value mechanics (since there is no output schema) and explicit differentiation from generate_barcode, but neither is critical for a simple generator.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of 'URL, text, or vCard data' merely restates the content parameter's schema description rather than adding new meaning (e.g., vCard formatting requirements or error-level semantics).

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

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

The description has a specific verb ('Generate'), a distinct resource (QR code), permitted input types (URL, text, vCard), and the output format (PNG image). This distinguishes it clearly from siblings like generate_barcode, generate_certificate, and generate_favicon without needing to inspect their schemas.

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

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

Usage is implied: use this when you need a QR code from URL/text/vCard input. However, there is no explicit guidance about when not to use it or mention of the closest alternative (generate_barcode), which sits directly in the sibling list and could reasonably be confused with a QR generator.

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

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

The file parameter description adds valuable behavioral context: the operation forces a full H.264 re-encode into MP4 with audio copied and is among the platform's slowest operations on long videos. Annotations already mark the tool as non-read-only and non-destructive, so the description extends that with performance and output-format expectations.

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

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

One lead sentence carries the action, resource, engine, and controls, plus a category tag. No filler or repetition.

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

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

For a 4-parameter tool with no output schema, the definition covers the required input, optional text, and validation fallbacks; the file description also telegraphs the output container (MP4) and the performance cost. A return-value description would tighten it, but the behavior is sufficiently inferable.

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

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

Schema description coverage is 100%, and the schema already documents defaults, ranges, enum values, and fallback behavior for opacity and position. The main description contributes only 'position and opacity control,' which duplicates existing schema detail rather than adding new semantics.

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

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

The description opens with 'Video Watermark' and uses a concrete verb, 'Overlay a text watermark onto a video using FFmpeg,' specifying the resource, the operation, and key controls. This is clearly distinguishable from siblings like photo_watermark and pdf_watermark, so an agent can select it without needing to inspect the schema.

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

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

The 'Video Watermark' framing and 'overlay onto a video' give clear context for when this tool applies, and the category tag narrows it to media. It doesn't explicitly name alternatives or exclusion conditions, but the video-specific wording makes the primary use case unambiguous.

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

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

The description adds meaningful behavioral context beyond the sparse annotations by naming FFmpeg, H.264 re-encoding, and quality presets. It does not explain output-file handling or non-destructiveness, but the schema's file parameter already documents the returned MP4 format.

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

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

The description is a single short sentence with the key behavior front-loaded. The 'Compress Video —' prefix and '[category: media]' tag are slightly redundant with the tool name and sibling context, but they add minimal overhead.

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

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

For a two-parameter tool with full schema coverage, the description plus schema is sufficient to select and invoke the tool correctly. Although there is no output schema, the file parameter description already specifies the H.264/AAC MP4 result, so the description does not need to repeat it.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already explains the output format for 'file' and the CRF mapping for 'quality'. The description only repeats the high/medium/low preset names without adding new parameter meaning.

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

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

The description states a specific verb-resource pair ('Compress Video') and explains the outcome (reduce file size) and method (H.264 re-encoding with FFmpeg). It is easy to tell apart from convert_video and media_trim_video, though it does not explicitly name an alternative.

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

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

The phrase 'Reduce video file size' implies the obvious use case, but there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives. In a large media/convert sibling set, an agent gets limited help choosing between this and convert_video or other compression tools.

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

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

The annotations (readOnlyHint:false, destructiveHint:false) provide little safety context, so the description should disclose side effects or output behavior, but it only restates the extraction action. The lossy/lossless encoding and 400-on-invalid-enum behaviors live in the param schema, not the tool description.

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

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

The description is one clear sentence and front-loads the action before the format list. It loses a point for repeating the 'Extract Audio' title and appending a category tag that adds little for an agent.

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

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

For a two-parameter tool with completely documented schema, the bare description is workable, but with no output schema it never describes the return value or how the extracted audio is delivered. It also omits usage boundaries relative to sibling audio/media tools.

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

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

Schema description coverage is 100%, so the schema already documents `file` and `format` thoroughly. The description adds the list of formats, matching the enum, but no extra semantic meaning beyond that baseline.

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

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

The description opens with a specific verb-resource pair ('Extract the audio track from a video file') and enumerates output formats, making the operation unambiguous. This clearly differentiates it from siblings like media_extract_frames, media_trim_audio, and media_merge_audio.

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

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

The description implies usage by naming the extraction task, but it never states when to prefer this tool over alternatives or what preconditions apply. With nearby siblings like media_extract_frames and media_trim_audio, an explicit 'use this when you need the soundtrack, not frames' would be stronger.

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

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

Annotations only provide generic flags (readOnlyHint=false, destructiveHint=false), so the description carries the behavioral burden. It clearly discloses that output is a ZIP of JPEG images and that extraction happens at a specified frame rate, giving the agent concrete expectations beyond the annotations.

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

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

The description is a single compact sentence with no unnecessary elaboration and front-loads the action and output format. The 'Extract Frames —' prefix is redundant with the tool name, which prevents a perfect score.

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

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

For a tool with no output schema, the description adequately covers the essential call details: input video, frame rate, and ZIP/JPEG output format. The schema fills in the remaining parameter defaults and constraints, so nothing critical is missing for a correct invocation.

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

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

The input schema already documents all three parameters with 100% coverage, including defaults, bounds, and descriptions. The tool description adds little parameter-level meaning beyond 'specified frame rate' and 'returned as a ZIP,' so it stays at the schema-driven baseline.

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

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

The description states a specific action and resource: extract frames from a video at a given frame rate, output as JPEGs in a ZIP. This clearly differentiates it from sibling tools like media_extract_audio and media_trim_video.

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

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

The intended usage is implied by the operation 'extract frames from a video,' but there is no explicit when-to-use guidance, exclusions, or comparison with alternatives. An agent can infer when to use it, but the description does not state this directly.

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

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

Annotations already indicate the operation is not read-only and not destructive. The description adds that the output is MP3 and that FFmpeg is used, but it does not disclose side effects, mixed-format handling, or output delivery behavior. This is a modest addition beyond annotations, not comprehensive.

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

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

The description is a single, efficient sentence with the essential constraint front-loaded and a useful category tag. There is no filler or redundant explanation.

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

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

For a one-parameter tool with annotations and a fully descriptive schema, the description provides enough information to invoke the tool correctly. A note about output/return behavior or ordering would make it fully complete, but nothing critical is missing.

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

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

The schema already documents the files parameter fully, including accepted formats and the at-least-2 constraint. The description only restates 'at least 2' and adds no new parameter-level semantics, so the baseline of 3 applies.

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

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

The description clearly identifies the operation (merge/concatenate), the resource (multiple audio files), the minimum count (at least 2), and the output format (one MP3 via FFmpeg). This distinguishes it well from sibling tools like media_trim_audio and media_extract_audio.

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

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

It gives a clear usage context: use this tool to concatenate two or more audio files into a single MP3. However, it does not explicitly name alternative tools or state when not to use it, so the guidance is sufficient but not exhaustive.

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

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

The description discloses the core behavioral effect: the audio track is removed, which goes beyond the annotations' readOnlyHint=false and destructiveHint=false. However, it does not clarify whether the input file is modified in place or a new muted video file is produced, which matters for an agent invoking the tool.

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

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

The description is a single front-loaded sentence that immediately states the verb and object. The category tag is compact and useful, and there is no redundant or filler text.

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

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

For a simple one-parameter tool with no output schema, the description sufficiently communicates the input and the transformation. It could explicitly mention the return value, but the fact that the result is a muted video is strongly implied by the operation.

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

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

The only parameter, 'file', is fully described in the input schema with its accepted formats (MP4, MOV, AVI, MKV), so schema coverage is complete. The description adds little parameter-specific meaning beyond calling it a 'video file,' so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Remove the audio track from a video file.' It clearly distinguishes the tool from related siblings like media_extract_audio or media_trim_video by describing a distinct outcome.

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

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

The description implies when to use the tool—when a muted/silent video is needed—but it gives no explicit alternatives, exclusions, or when-not-to-use guidance. It does not mention related media tools such as media_extract_audio or media_trim_video.

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

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

Annotations already signal a non-read-only, non-destructive safety profile, lowering the bar. The description adds only 'using FFmpeg' as mechanism context; it does not disclose whether the original file is overwritten, where the output is written, or whether the operation is lossless versus re-encoded. The stream-copy behavior is mentioned in the file parameter schema, not the description.

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

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

One front-loaded, single-purpose sentence with no filler. Minor redundancy: the leading title 'Trim Audio' restates the verb+resource of the following sentence, and the '[category: media]' tag contributes little value to an agent.

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

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

For a simple 3-parameter tool with 100% schema coverage, safety annotations, and no nested objects, the description plus schema is nearly sufficient for correct invocation. The main gap is explicit output file naming/overwrite behavior, which is only hinted at through the schema's note that an extension-less filename is treated as .mp3.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'start and end time' phrase loosely maps to the start/end parameters but adds no format guidance, default values, or constraints beyond what the schema already fully documents.

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