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

With no annotations, the description discloses the QAG grading method, return type (score, passed, reason), and the use of a judge model. It does not mention side effects or API dependencies, but for an eval tool this 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 concise, with two focused paragraphs. The first paragraph states the purpose and method, the second details parameters and return value. No filler or redundant 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?

Given the absence of an output schema, the description still provides the return format and explains the QAG method. It covers the essential aspects but could mention edge cases or error handling for 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?

Despite 0% schema description coverage, the description provides clear parameter semantics: expected_answer (ground-truth), actual_answer (LLM's answer), judge_model (provider:model). This compensates fully for the lack of schema descriptions.

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 tool evaluates semantic equivalence of answers to ground truth using QAG, distinguishing it from strict string matching. Among sibling eval tools, this purpose is distinct and well-defined.

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 includes a clear usage guideline: 'Useful when string match is too strict (e.g. paraphrased correct answers).' It provides context but does not explicitly differentiate from other eval tools like eval_faithfulness or eval_hallucination.

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?

With no annotations, the description carries the full burden. It explains the tool combines multiple inputs and writes a ZIP file, listing contents (run JSON, case PDFs, answer keys, JUnit XML, manifest). It also describes the return value structure. However, it does not mention potential side effects like file overwriting or error handling, which would elevate it to 5.

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 well-structured: a concise one-line summary, followed by a brief paragraph on contents, then Args/Returns. It is front-loaded with the purpose. While somewhat lengthy for a simple tool, every sentence adds value and the structure aids readability.

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 the tool has 3 required parameters and no output schema shown (though context says one exists), the description covers inputs and return structure thoroughly. It includes a note about the manifest's utility. Missing elements are prerequisites (e.g., run must have been executed) and error conditions, but overall it is complete for typical use.

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 lacks descriptions (0% coverage). The description compensates fully with a dedicated 'Args' section that explains each parameter in context: run_json_path is from 'pdfhell run --out', cases_dir contains case PDFs and answer keys, output_zip_path is where to write. This adds essential meaning beyond the schema's type-only 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 starts with a clear, specific verb-resource combination: 'Build a hash-chained audit ZIP from a pdfhell run.' It defines the output format and distinguishes itself from sibling tools (eval_*, pdfhell_make/run) which focus on evaluation metrics or execution, not packaging.

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 states the tool is 'Suitable for attaching to a procurement diligence appendix,' providing a concrete use case. It implies usage after a pdfhell run, but does not explicitly exclude scenarios or name alternatives. Context with sibling tools clarifies its distinct role.

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?

With no annotations provided, the description carries full burden. It explains the QAG-graded mechanism (five yes/no questions), score range (0.0-1.0), and return fields (score, passed, reason, threshold, evaluator). It also notes that input contextualizes whether disparate treatment is justified. Minor gaps: no discussion of failure modes or rate limits.

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

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

Description is well-structured: first sentence defines purpose, then mechanism, use cases, args, and returns. Every sentence adds value, and the most critical 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?

Given 3 parameters, no nested objects, and an output schema (whose structure is described), the description is thorough. It covers purpose, usage, mechanism, all parameters, and return format. No gaps for an evaluator 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 0%, so description must carry all parameter meaning. It does so comprehensively: explains 'input' as the prompt for context, 'output' as the LLM response, and 'judge_model' with a default provider:model. Adds significant meaning beyond the raw 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 purpose with a specific verb ('Detect') and resource ('bias'), listing multiple bias types (gender, racial, political, etc.). It distinguishes from siblings like eval_toxicity by focusing on fairness audits rather than harmful content.

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 states when to use this tool: 'fairness audits on generated content, summarisation of user-submitted text, or hiring/lending-adjacent LLM pipelines.' It provides clear context but does not explicitly state when not to use it or list 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?

Given no annotations, the description discloses key behaviors: reads files from disk, pairs by case_input, computes deltas, and includes McNemar p-value for statistical significance. It is transparent about the operations and return values, though it could mention if the tool has any side effects (likely none).

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 well-structured: a one-sentence summary, an explanation of functionality and use case, parameter listing, and detailed return format. Every sentence adds value, and it is concise given the complexity.

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 two parameters fully explained and the return format detailed in the description (including nested dicts and lists), the description is complete. It also explains the logic (pairing, McNemar test) and provides context for interpreting results.

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 has 0% description coverage, but the description provides an 'Args' section explaining both parameters (baseline_json_path and new_json_path) with examples. This fully compensates for the schema's lack of descriptions.

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 it compares two eval report JSONs and returns a structured diff. It uses a specific verb (compare) and resource (multivon-eval report JSONs), and the purpose is distinct from sibling tools that evaluate single aspects.

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 specifies when to use (after making a prompt/retrieval/model change to assess improvement) and provides context for case-by-case analysis. However, it does not explicitly mention when not to use or list alternative tools, though the sibling context implies uniqueness.

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?

Describes the judge process (each chunk up to 8, fraction relevant) and output format. With no annotations, the description adequately covers behavioral 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?

Well-structured with clear sections (purpose, usage, args). Each sentence is informative, no fluff. Appropriate length.

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 the output schema exists and describes return values, the description is complete: explains inputs, process, and return. No 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?

Provides meaningful descriptions for all three parameters despite 0% schema coverage. Explains input, context formats, and judge_model default. Adds value 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 tool measures relevance of RAG context chunks to a question, defines high precision, and distinguishes it from sibling tools like eval_context_recall. The verb 'measure' and resource 'context precision' are specific.

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 says to use for diagnosing retriever quality and gives examples of what low precision indicates. Does not explicitly mention when not to use or alternatives, but the 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?

No annotations exist, so the description carries full burden. It explains the judge's role: 'asks whether the expected answer could plausibly be reconstructed from the retrieved context alone.' It also defines 'high recall.' No destructive side effects are expected, and the behavioral disclosure is adequate.

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 well-organized: a short summary, a clarification paragraph, an explicit usage line, and an Args section. It is efficient without being wordy, though it could be slightly more 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?

Given the tool's complexity and the presence of an output schema, the description covers all essential aspects: purpose, usage context, parameter meanings, and the return structure (score, passed, reason, threshold, evaluator). This is fully sufficient for correct agent 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 0%, so the description must compensate. It lists all four parameters (input, context, expected_answer, judge_model) with brief but clear explanations. For example, it notes that context can be a list or single string. This adds meaning beyond the raw 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 starts with a clear one-sentence purpose: 'Measure whether retrieved context contains enough information to answer.' It specifies the resource (retrieved context) and the action (measuring recall). The context of retriever vs. generator diagnosis distinguishes it from sibling tools like eval_context_precision or eval_faithfulness.

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 states when to use: 'when you have a labelled QA dataset and want to diagnose whether failures are retriever misses vs. generator errors.' It clearly sets the context but does not explicitly mention alternatives or when not to use it, leaving some room for improvement.

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?

No annotations are provided, so the description carries the full burden. It transparently explains the scoring mechanism (yes/no per criterion, fraction correct) and notes the use of a judge model. It does not disclose any destructive behavior (none expected) and adequately describes the evaluation process.

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 well-structured with an introduction, use-case paragraph, and enumerated arguments. It is appropriately sized for a tool with 6 parameters and a return value. A minor improvement could be trimming some redundant phrasing, but overall it is concise and easy to scan.

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 the tool has 6 parameters with no schema descriptions, and an output schema is present, the description covers all parameters and the return value (mentioning keys like score, passed, reason). It provides enough context for correct invocation, including examples and default values, making it complete for an evaluation 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 0%, so the description must fully explain parameters. It provides an Args section with clear definitions, including an example for the 'criteria' parameter that adds significant meaning beyond the schema's type-only specification. All six parameters are explained with defaults and types.

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 'Score an output against your own list of yes/no quality checks', clearly identifying the tool's purpose as a custom rubric evaluator. It distinguishes from sibling evaluation tools by noting it's for compliance-style rubrics, making its specific role clear.

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 'Best for compliance-style rubrics where each aspect should be auditable separately', providing clear context for when to use the tool. However, it does not mention when not to use it or explicitly contrast with sibling tools, but the guidance 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?

No annotations are provided, so the description carries full burden. It discloses the return structure in detail (three keys: evaluators, traps, suites) and mentions it is machine-readable. It does not mention side effects or permissions, but the tool is read-only and safe.

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 fairly concise with a clear structure: a lead sentence, usage note, and a bullet-like list of return keys. It could be slightly shorter, but it is well-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?

Given the tool's simplicity (zero parameters), the description is complete. It explains the purpose, usage context, and output structure in sufficient detail. Even with an output schema present, the description provides all necessary information.

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 tool has zero parameters, and schema coverage is 100% (no props). The description adds value by detailing the output structure, which is not captured in the input schema. This compensates for the lack of parameters.

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 purpose: 'Return the full machine-readable capability catalog.' It distinguishes itself from sibling evaluation tools by positioning itself as the initial discovery call, unlike the other eval tools that perform specific evaluations.

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 advises using this tool as a first call at session start to plan evaluation strategy, providing clear context. It does not explicitly say when not to use it, but the sibling names imply it is for initial discovery before 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?

With no annotations, the description carries full transparency burden. It explains the vision judge evaluates three criteria, returns a structured response, and requires images per page. It lacks disclosure on performance implications or auth requirements, but for an evaluation tool, this 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 concise and front-loaded with purpose, then uses Args/Returns structure to detail parameters and output. It is efficient with no wasted words, though slightly more structured formatting (e.g., line breaks) could improve readability.

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 6 parameters, 0% schema coverage, and an output schema, the description covers all aspects: required inputs, optional parameters, defaults, and return format. It misses edge cases like handling both image options, but overall sufficient 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 coverage is 0%, but the description fully documents all 6 parameters: input, output, images (paths/URLs/data URIs), images_base64 (alternative), mime_type (default png), judge_model (default and vision capability requirement). It explains constraints like using exactly one of images or images_base64, adding meaning 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 tool checks document grounding for multi-page documents, specifying it answers three yes/no questions via a vision judge. This distinguishes it from sibling evaluation tools like eval_faithfulness or eval_vqa_faithfulness by being explicitly document-page-grounded.

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 usage guidelines: specify input and output, provide one image per page using exactly one of images or images_base64, and optionally set mime_type and judge_model. However, it does not explicitly contrast with alternative tools or state when not to use it.

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

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

With no annotations, the description carries the full burden. It explains the evaluation process: extracts factual claims, verifies each against context, and provides a score. It also specifies the default judge model and hints at its calibration. It lacks details on error handling or permissions but is fairly transparent.

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 well-structured and concise: a one-sentence purpose, a brief explanation of the evaluator, a use-case line, then bullet-style parameter descriptions and a return format. Every sentence adds value 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?

The description covers the tool's purpose, usage context, behavioral details, parameter meanings, and return format (matching the output schema). For a tool with 4 parameters and no nested objects, this is comprehensive.

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 0%, so the description must compensate. It describes each parameter: 'input' as the user's question, 'context' as retrieved context, 'output' as LLM answer, and 'judge_model' with a default and hint. This adds meaning beyond the bare schema, though not extremely detailed.

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 tool evaluates whether an LLM output is grounded in retrieved context, using a specific evaluator (QAG-graded Faithfulness). It differentiates from sibling tools like eval_hallucination by focusing on factual claim verification against context.

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 when to use: 'when a RAG pipeline returned an answer and you want to check the LLM didn't invent facts.' It does not mention when not to use or name alternative tools, but the context of use is well-defined.

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?

With no annotations provided, the description carries full burden. It discloses that the tool calls an external generator, requires an API key, and returns a specific data structure. It does not mention potential latency or costs, but is transparent about the dependency on an underlying judge model and the generation process.

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 one-sentence summary. It then follows a structured docstring format with Args and Returns sections. While somewhat lengthy, each sentence adds value; minor redundancy could be trimmed without losing 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 the complexity (4 parameters, no schema descriptions, no annotations), the description covers purpose, parameters with defaults, output structure, and prerequisites (API key). It does not mention error handling or edge cases (e.g., API failure), but for a generation tool, the provided information is sufficient for an agent to use it 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 0%, so the description must compensate. It provides a detailed 'Args' section explaining each parameter: 'from_text' (source text), 'n' (number of cases, default 10), 'task' (QA, summarization, hallucination with explanations), and 'judge_model' (provider:model string with default). This fully adds meaning 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 verb 'Generate' and the resource 'synthetic eval cases' from a source text. It distinguishes itself from sibling evaluation metrics by focusing on generation rather than evaluation, and provides specifics like producing 'input', 'expected_output', and 'context' for each case.

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 mentions eliminating the cold-start problem when building an eval suite, implying use when starting from scratch. It also notes the requirement of a provider API key. However, it does not explicitly state when not to use or provide alternatives among siblings, though the sibling tools are mostly evaluation metrics, making this tool's purpose distinct.

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?

No annotations are provided, so the description carries full burden. It discloses that two independent runs are averaged by default to mitigate position/framing bias, and describes the return format. It does not discuss authorization, rate limits, or destructive effects, but those are not critical for a scoring 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 well-structured with a summary line, usage guidance, parameter list, and return format. It is front-loaded with the core purpose. Every sentence adds value, and there is 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?

Given 6 parameters, no annotations, and an output schema (described in text), the description is comprehensive. It covers purpose, behavior, parameters, return format, and sibling comparison. No gaps are evident for the tool's complexity.

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 0% (no parameter descriptions in schema), but the description's Args section provides detailed semantics for each parameter: input, output, criteria, name, runs, judge_model. It explains defaults and purpose, fully compensating for the schema's lack.

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 it performs 'G-Eval style holistic scoring against a plain-English criterion', using specific verbs and resources. It distinguishes from sibling eval_custom_rubric by noting that tool is better for 'criteria with multiple discrete aspects'.

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 recommends this tool for 'fuzzy or holistic qualities' and explicitly names eval_custom_rubric as an alternative. It also explains the dual-run averaging for variance reduction. However, it lacks explicit when-not-to-use guidance beyond the alternative mention.

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?

No annotations exist, so description carries full burden. It describes return format but does not disclose if it makes external API calls via judge_model or any side effects, permissions, or rate limits.

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

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

Front-loaded purpose, concise arguments and returns sections. Could be slightly tighter if output schema were present, but overall efficient.

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?

Covers purpose, parameters, and return structure, but lacks usage guidance and behavioral context. Given medium complexity and available output schema, gaps remain.

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?

Adds clear explanations for each parameter beyond the schema (e.g., 'The LLM output to check', 'Provider:model for the QAG judge'), compensating for zero schema description 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?

Clearly states it detects fabricated information not in context. Differentiates from siblings by naming hallucination detection but does not explicitly compare to eval_faithfulness or others.

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?

Provides score interpretation but lacks guidance on when to use this tool versus alternatives like eval_faithfulness, and no 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?

No annotations are provided, so the description carries the full burden. It discloses supported frameworks, expected input structure (trace_json must include input and steps), and the return shape (keys like input, expected_output, agent_trace). It does not cover error handling or edge cases, but for a conversion tool, the disclosure is adequate.

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 well-structured with a clear summary, usage guidance, framework details, and structured Args/Returns sections. It is informative without being overly verbose, though it could be slightly shorter while retaining 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 the tool's complexity (multiple frameworks, conversion task) and minimal schema, the description is complete. It explains the output shape (return dict keys) so that the agent knows how to use the result with other eval_* tools. The presence of an output schema in signals does not detract from the description's 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?

The schema has 0% description coverage, so the description must compensate. It does so thoroughly: explains that trace_json must include 'input' and 'steps' (or 'new_items' for openai_agents), and lists the three valid framework values. This adds significant meaning beyond the raw 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 exactly what the tool does: 'Convert a JSON agent trace into a JSON-friendly EvalCase payload.' It is specific about the verb ('Convert') and the resource ('agent trace into EvalCase payload'), and it clearly distinguishes itself from sibling eval_* tools by focusing on trace ingestion rather than evaluation.

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 when to use: 'Use this when your agent has just finished a trajectory at runtime and you want to score that trajectory immediately.' It provides context for usage but does not explicitly state when not to use it or compare to alternatives. The guidance is clear but could be more comprehensive with 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?

With no annotations provided, the description fully discloses behavioral traits: local-only operation, scoring (1.0 for no PII, 0.0 for PII found), and the redact feature. It adds value beyond the input schema by explaining the purpose and effects of parameters.

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 well-organized: a one-line purpose, a brief feature paragraph, scoring explanation, and a list of args. It is concise but not overly brief; each section adds useful information. Slight room for tightening, but overall effective.

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 description covers all necessary aspects: purpose, usage context, parameter details, and a return format example. Given the presence of an output schema (context signal), the return values are explained, ensuring the agent has complete information to use 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 0%, but the description thoroughly explains each parameter: 'output' (text to scan), 'jurisdiction' (lists possible values), 'custom_patterns' (dict of name:regex), and 'redact' (boolean for replacements). This fully compensates for the lack of schema descriptions.

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 tool's action: 'Detect personally-identifiable information (PII) in an LLM output.' It identifies the specific resource (LLM output) and verb (detect), and differentiates from sibling eval tools by focusing on PII detection.

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 notes 'Local-first: zero API calls,' implying safe deployment without external dependencies. It also explains jurisdiction and custom patterns options, providing context for use. However, it does not explicitly state when to avoid using this tool or compare to alternatives like toxicity detection.

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?

With no annotations provided, the description carries the full burden. It discloses the QAG method and the return structure, but does not mention side effects, permissions, rate limits, or determinism. The behavioral disclosure is adequate but 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 short, front-loaded with the purpose, and structured with Args and Returns sections. Every sentence is necessary and no extraneous information 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?

Given the tool has 3 parameters and an output schema described in the returns, the description covers the main points: method, parameters, and return values. However, it misses explaining the threshold default and configuration, and lacks guidance on when to use this tool versus siblings. Still, it is largely 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 coverage is 0%, so the description must add parameter meaning. It clearly explains input as 'The user's question', output as 'The LLM's response', and judge_model with format 'Provider:model'. This adds value beyond the schema's titles and types. A slight deduction for lacking constraints on judge_model values.

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 tool checks if an LLM output addresses the user's question, using a QAG-graded method. This is a specific verb+resource, and the method detail (generates yes/no questions) distinguishes it from sibling evaluators like eval_answer_accuracy or eval_faithfulness.

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 for relevance checking, but does not explicitly provide when-to-use or when-not-to-use guidance relative to sibling tools. No alternatives or exclusions are mentioned, which is a gap given the presence of many similar eval_* 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?

No annotations are provided, so the description carries full burden. It thoroughly explains behavior: tolerant parsing (strips markdown fences), per-field validation errors, strict mode effect, and the exact return format. No contradictions.

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 well-structured and front-loaded with the purpose. It is slightly lengthy due to parameter and return details, but each sentence adds value. Could be slightly more concise without losing 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 the tool's complexity (3 parameters, output schema exists), the description is complete. It explains the return format, error handling, and parameter semantics. No gaps remain for the agent to guess.

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 0%, but the description compensates fully with detailed parameter explanations: 'output' as LLM-generated text, 'schema' with a concrete JSON Schema example, and 'strict' with its boolean effect. This adds significant meaning 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 tool's purpose: 'Validate that an LLM output conforms to a JSON Schema.' It differentiates from sibling eval tools by focusing on schema compliance, and mentions internal details that help the agent understand its 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?

Explicit usage guidance is provided: 'For Pydantic-model validation or more advanced setups... use the multivon-eval SDK directly.' This tells the agent when not to use this tool, and the description explains the tool's capabilities (tolerant parsing, per-field errors) that help decide when to use it.

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?

No annotations provided; description carries burden. It discloses deterministic behavior (no LLM), input parameters (expected/actual), and return format (score, passed, reason). Does not mention side effects, which is acceptable for a stateless evaluation 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?

Description is succinct (~8 lines) with clear sections: purpose, behavior, args, returns. No wasted words; structure facilitates quick scanning.

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 the tool's simplicity and presence of output schema, the description fully covers inputs, deterministic behavior, and return value. No gaps for an agent to use it 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 coverage is 0%, but description adds meaning via Args section: explains each parameter (expected_tool, actual_tool, etc.) and notes optionality of arguments. Provides clarity beyond schema's type-only 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?

Description clearly states the tool evaluates tool call accuracy by comparing actual vs expected tool names and arguments. It distinguishes itself from sibling eval tools by focusing on tool call correctness and emphasizing deterministic nature without LLM judge.

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?

Description implies usage for objective evaluation but lacks explicit guidance on when to use this tool versus other eval tools like eval_answer_accuracy or eval_faithfulness. No when-not recommendations are given.

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?

No annotations are provided, so the description carries full burden. It describes the scoring logic (four yes/no questions, fraction), the returned output schema, and that it evaluates LLM output. It does not mention any destructive side effects, which is appropriate for a read-only evaluation 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 concisely structured with a clear one-line purpose, followed by grading details, usage guidance, and parameter explanations. Every sentence adds necessary information without 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?

Given the tool's simplicity (2 parameters, output schema provided), the description covers all necessary aspects: purpose, scoring method, usage context, parameter details, and return value structure. No gaps remain.

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 0%, but the description adds full meaning: 'output' is defined as 'The LLM-generated text to evaluate' and 'judge_model' is explained with examples and default. This compensates entirely for the schema's lack of descriptions.

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 tool detects harmful content in LLM output, with a specific verb 'detect' and resource. It explains the QAG-grading mechanism, distinguishing it from sibling eval tools like eval_bias or eval_hallucination.

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 to use for guardrails, chatbot turns, or user-facing LLM output where harmful content is a risk. It provides clear context but does not mention when not to use or compare directly to 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?

No annotations are provided, so the description carries the full burden. It discloses the scoring mechanism (fraction of accurate claims), the use of a vision judge model, and the return format. Does not mention side effects, but as a read-only evaluation tool, this 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?

Well-structured with clear sections: summary, process, use cases, image input options, args, and returns. Every sentence adds value. Could be slightly more concise, but the structure aids readability.

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 the tool's complexity (6 parameters, 2 required, output schema textually described), the description is comprehensive. Covers all parameters, return values, and use cases. Does not mention error handling, but for an evaluation tool this is 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?

Schema description coverage is 0%, but the description fully compensates by explaining all 6 parameters including formats, defaults, and alternatives. Input and output are clearly described, image input options are detailed, and judge_model options are provided with examples.

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 tool's purpose: checking if an LLM answer about an image is grounded in what's visible. It explains the process (extracts up to 3 claims, verifies each) and distinguishes from sibling tools like eval_faithfulness by focusing on image-grounded evaluation.

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 lists use cases: visual QA, image captioning, chart/diagram reading, and any LLM output describing an image. Provides guidance on judge model selection (including not using Haiku). Could be improved by explicitly stating when not to use (e.g., for text-only faithfulness), but the 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?

No annotations are provided, so the description bears full responsibility. It discloses output structure (dict with case JSON and optional PDF bytes) and behavioral guarantee (same seed yields identical output). No destructive side effects are implied, which is appropriate for a generative 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 well-structured with a summary line, usage context, and an Args/Returns list. Every sentence adds value, though it is slightly verbose. It front-loads the primary purpose.

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 the presence of an output schema and the tool's simplicity, the description covers essential aspects: output structure, parameter semantics, and usage context. It is sufficient for an agent to 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?

With 0% schema description coverage, the description fully explains all three parameters: trap (family name, examples, source of truth), seed (integer, determinism), and return_pdf_bytes (default behavior and purpose). This goes well beyond the bare 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 tool's purpose: 'Generate one adversarial PDF + its answer key.' It uses a specific verb-resource pair and distinguishes itself from siblings like eval_discover and pdfhell_run by noting that eval_discover lists trap families.

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 explains when to use this tool ('to inspect what a specific trap looks like before deciding to evaluate against it') and provides guidance on obtaining trap family names via eval_discover. It does not explicitly exclude scenarios but gives clear context for typical usage.

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?

With no annotations provided, the description fully carries the burden. It discloses that it runs a benchmark, calls external APIs using environment variables (with keys like ANTHROPIC_API_KEY), and that keys are not logged. It also describes the return value structure. This provides good behavioral insight, though it does not explicitly state non-destructive or rate-limit behaviors.

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 well-structured with 'Args' and 'Returns' sections, making it easy to parse. It uses bullet points for suite options and includes example formats for model. Every sentence provides useful information; there is no fluff. It is appropriately sized for the tool's complexity.

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 an output schema exists, the description needs not detail return values fully. However, it does summarize the return dict and notes that suite version/hash are included. It covers the tool's purpose, all parameters with defaults, and additional context about environment variables. The description is complete for this tool's 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 input schema has 0% description coverage, so the description must compensate. It does so excellently: model format with examples, suite options with case counts and cost estimates, and workers with default. This adds significant meaning beyond the raw schema types. Every parameter is explained with concrete 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 starts with 'Run the pdfhell adversarial-PDF benchmark against a vision model,' which clearly states the verb (run) and resource (adversarial-PDF benchmark). This distinguishes it from sibling eval_* tools and pdfhell_make, all of which have different purposes. The purpose is specific and immediately understandable.

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?

While the description explains what the tool does and details the parameters, it does not explicitly guide when to use this tool versus alternatives like pdfhell_make or other eval tools. It implies usage when running a pdfhell benchmark, but no explicit when-to-use/when-not-to-use guidance is provided. The lack of differentiation from siblings limits the score.

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