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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that not all pairs are supported and that list_document_conversions should be consulted, which is helpful. However, it doesn't explicitly state side effects (like file writes) or the inline bytes behavior, though these are partly covered in the schema. Given no annotations, this is strong but could mention reversible or destructive aspects if any.

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 two sentences in the main text, with no filler. It front-loads the purpose and formats, then adds a crucial usage note. Every sentence earns its place, and the length is appropriate for the complexity of the tool.

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 params, nested objects, output schema), the description is complete: it covers supported formats, limitations, how to verify, and references the companion tool. The output schema exists, so return values need not be described. The description handles the core decision points an agent needs.

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 explaining that images are only used for markdown-source conversions and that fonts are only used for layout engine (pdf) conversions, which goes beyond the schema descriptions. It also clarifies the output behavior (inline vs path) more explicitly. This takes it above 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 verb ('Converts') and resource ('document...via documents.js's DocumentConverter port'), lists supported formats explicitly, and distinguishes the tool from siblings by referencing list_document_conversions (a sibling that checks supported pairs). It clearly communicates what the tool does and how it differs from related 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 explicitly instructs to call list_document_conversions first to confirm supported pairs, which provides when-to-use guidance and directs to the alternative tool. It also covers edge cases (odf only converts to pdf), giving clear usage context beyond the 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?

With no annotations, the description carries the burden of behavioral transparency. It states that the tool 'reads' (implying non-mutating) and that it reports what the font 'declares about itself,' which clarifies it only examines metadata, not the actual glyphs or rendering. It also adds context that the input is a standalone file, not a document. It doesn't discuss error handling or edge cases, but for a simple read operation, this 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 a single, front-loaded sentence that immediately states the action ('Reads'), the resource (standalone .ttf/.otf), and the output (family/bold/italic triple). Every word adds value, with no filler or repetition. It is a model of conciseness.

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 low complexity (one parameter, no output schema), the description is sufficient: it explains the purpose, the input type, and the output. It does not explicitly mention when to use it versus alternatives, but for a simple read-only tool, the description is complete enough for an agent to select and invoke it correctly. The 'not a document' note helps prevent misuse.

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 100% coverage for the single parameter 'source', including a clear description and detailed union alternatives (path or bytesBase64). The tool description does not add additional semantic meaning beyond what the schema already provides. Therefore, 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 clearly states the tool's purpose: it reads a standalone TrueType/OpenType font file and reports the family/bold/italic triple it declares. This is a specific verb and resource, and specifying the output distinguishes it from sibling tools like 'fonts' or 'pdf_inspect' which may handle fonts in other contexts.

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 use case: when you have a standalone .ttf/.otf file and need its declared metadata. It emphasizes 'standalone' and 'not a document,' but does not explicitly mention alternatives or when not to use this tool. While the context is fairly clear, the lack of explicit comparison to sibling tools leaves this at the 'implied usage' level.

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 behavioral burden. It communicates a read-only operation and specifically says it returns 'the real DocxExtras object' with listed parts. It doesn't cover edge cases like missing optional parts, but for a straightforward read extraction this is reasonable.

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 exactly two sentences with no filler. The first sentence states the action and scope, the second clarifies the return type and value; even the explanatory rationale earns its place by differentiating from other tools.

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 lists all major data categories in the return object, which partially compensates for the absence of an output schema. The tool itself is simple (one parameter) and the description is sufficient for an agent to select it for extracting inaccessible docx subcomponents. Minor undocumented edge cases are acceptable here.

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 for the single parameter is 100%, with the schema already explaining source, path, bytesBase64, and format. The tool description adds no new param-specific semantic value, so the baseline of 3 is appropriate because the schema does the heavy lifting.

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: 'Reads a docx's own comments, footnotes, headers, footers, and numbering definitions.' It clearly distinguishes this tool from ordinary document readers by explaining that the ContentDocument pivot cannot carry this data, so sibling tools won't expose it.

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 choose this tool: when comments/footnotes/headers/footers/numbering are needed, because ordinary document-reading tools cannot see them. It lacks an explicit sibling alternative or explicit when-not-to-use guidance, 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 carries full burden. It clearly indicates a read-only listing action and describes the output. However, it does not mention potential edge cases, error conditions, or performance implications, which are not critical for a simple listing 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, focused sentence with no redundant information. It is concise and well-structured, directly stating the action and output.

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 provides essential information about the expected return (font family, weight, byte length). It also lists supported formats. It is sufficient for understanding the tool's output, though it does not detail the exact structure (e.g., list vs. object) or error 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?

The input schema already fully describes the 'source' parameter with its two possible forms (path or bytesBase64+format). The tool description does not add additional meaning beyond restating the supported formats. With 100% schema coverage, a 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 clearly states the tool's function: listing every source-embedded font face in supported document formats, and specifies the returned attributes (family, weight, byte length). It is specific and unambiguous.

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

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

The description does not explicitly state when to use this tool over the alternatives (e.g., describe_font_file) or provide any conditional guidance. While the purpose is clear, it lacks explicit usage context or 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 carries the full burden of behavioral disclosure. It mentions rebuilding bytes and being the read side of a round trip, but fails to note practical behaviors such as writing to outputPath vs returning inline bytes, potential overwriting, or that the 'format' field in source is unused. This lack of transparency could lead an agent to make incorrect assumptions about 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 a single, dense sentence that packs technical terminology. It is not overly long, but it is not front-loaded with the most accessible information and could be split into clearer sentences. The jargon reduces conciseness from a readability standpoint.

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 provides useful conceptual context about the round-trip workflow, which helps an agent understand when and why this tool exists. However, it omits practical details like output modes (file vs inline) and any prerequisites or limitations. The rich schema covers parameters, but the lack of annotations and output schema means the description should offer more operational context. It is adequate but with 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 the baseline is 3. The description adds the round-trip context but does not enrich parameter meanings beyond what the schema already provides. The schema already explains fields like 'source', 'targetFormat', and 'output' in detail, so the description's contribution here is minimal.

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 'Rebuilds real document bytes in a target format from a DocumentPackage previously serialised to JSON', which is a specific verb+resource. It also frames it as the 'read side of the DocumentPackage round trip', distinguishing it from sibling conversion tools. However, the jargon ('DocumentPackage', 'onDocument callback') may not be immediately accessible to all agents, so it misses a perfect score.

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 through the round-trip context and reference to a prior '--dump-package-equivalent step', but there is no explicit guidance on when to use this tool versus alternatives like convert_document or when to avoid it. The description would benefit from a direct statement like 'Use when you have a serialized DocumentPackage JSON and need to reconstruct a document.'

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 burden. It explains the tool reads from documents.js's port, indicating it's a read-only operation, but doesn't detail output structure or performance. It adds value by establishing authority, but leaves some behavioral details (e.g., output format, potential errors) undisclosed.

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 sentence, but it is packed with purpose and context. It is efficient and front-loaded with the core function, though it could be slightly more concise by trimming the 'definitive source of truth' phrase, which is somewhat redundant with the rest.

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 no parameters and an output schema exists, the description covers the key aspect: what the tool lists and its authoritative source. It doesn't detail the output format, but that's covered by the output schema. The description is adequate for a simple listing 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?

The tool has zero parameters, so the description doesn't need to explain parameters. The base for 0 parameters is 4, and the description appropriately focuses on what the tool returns (the format pairs), which is the needed semantic context.

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 lists every (source, target) format pair that convert_document supports, directly tying it to the definitive source of truth. It distinguishes itself from siblings by explicitly naming convert_document and framing this tool as the reference for convert_document's capabilities.

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 it: to know what convert_document will or will not accept. It doesn't explicitly say when NOT to use it, but the context of the sibling tools and the focus on format pairs make the intended use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so excellently. It reveals a surprising implementation detail: that xlsx metadata is read via a throwaway xlsx-to-pdf preview, which may affect performance or side effects. It also notes that odf is a standalone formula document, giving the agent insight into internal handling. This exceeds expectations by offering transparency beyond simple 'reads metadata'.

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 sentence but efficiently packed with information. It front-loads the main purpose and then adds relevant edge-case details in a parenthetical. Every word earns its place; no fluff or redundancy. It is concise and well-structured.

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 moderate complexity (multiple formats, edge cases) and the absence of annotations and output schema, the description is remarkably complete. It covers the tool's scope, special behaviors (xlsx via preview, odf as standalone), and implicitly clarifies what fields are read. The only minor gap is not detailing the exact return structure, but without an output schema, this is acceptable. This is a high-quality 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?

The schema covers 100% of the parameter descriptions, so the baseline is 3. The description adds value by explicitly listing the metadata fields read (title, author, subject, keywords, creator, producer, timestamps), which clarifies what the output may contain, even though there is no output schema. This additional semantic detail justifies a 4.

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: reading a document's own metadata fields (title, author, subject, keywords, creator, producer, timestamps). The verb 'reads' and the specific resource 'document metadata' are precise and differentiate it from siblings like metadata_write and outline_document. It also explicitly notes format coverage, including edge cases (xlsx, odf), which further distinguishes it from potential alternatives.

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 on when to use this tool: for reading a document's own metadata across supported formats. It does not explicitly list when not to use it or mention alternatives like metadata_write for setting metadata, but the context is clear enough for an agent to infer that this is for reading. Since there is no explicit exclusion or alternative guidance, the score is 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?

With no annotations provided, the description carries full responsibility for disclosing behavior. It clearly states it leaves other fields/flags as-is, does not convert format, and rejects odf outright. It could add more detail about side effects or error handling, but the key constraints are well-communicated.

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 3 sentences, front-loaded with the core action, then constraints, then actionable advice. No fluff, every sentence provides new 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?

For a patching tool with 7 parameters and no output schema, the description is thorough: it explains the exact semantic of the setters, the format matching constraint, rejection of odf, and a path forward. Sibling tools confirm it's part of a document handling suite, and the description aligns well with that 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?

Schema description coverage is 100%, so parameters are already documented. The description adds value by clarifying that omitted set* fields remain unchanged ('leave it exactly as the source document already has it') and that targetFormat must match the source format, which is not fully obvious from the enum alone. This complements 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 'patches a document's own title/author/subject/keywords' and explicitly differentiates from format conversion, which distinguishes it from sibling tools like convert_document and metadata_read. It accurately reflects the name and title.

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 explicitly states when not to use (odf rejection, format mismatch) and provides direct guidance to convert first if needed, naming the alternative tool category. This gives clear when/to/not-to use instruction.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not state that the operation is read-only or non-destructive, nor does it mention any side effects, permissions, or output format. A simple listing operation is implied but not explicit.

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 that front-loads the purpose and key output details. It contains no wasted words and is easily parseable.

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 simplicity of the tool (one parameter, no output schema), the description is adequate. It provides enough context to distinguish forms from other .odb entities and lets the schema handle parameter details. It does not explain return format, but for a listing tool this is often 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?

The tool description adds no parameter-specific details, but the input schema's description of 'source' is comprehensive (100% coverage), including why odb is excluded from document formats. Since the schema fully documents the parameter, the description's silence is acceptable, but no extra value 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?

The description clearly states the tool lists all forms in an .odb database, with specifics about data sources and field-bound controls. This distinguishes it from sibling tools like odb_tables and odb_reports, which handle other entity types.

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 that this tool is for forms in .odb databases, implicitly distinguishing it from siblings that target tables, reports, and queries. It does not explicitly state when not to use it, but the naming and context make usage 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?

No annotations are provided, so the description carries the full burden. It transparently discloses the bounded single-table nature, the in-memory execution over extracted tables, the closed grammar (no joins/subqueries), and that unsupported constructs are reported as tool errors, never silently ignored. This is rich behavioral disclosure, though it could add a note about side effects (none implied) or potential performance limits, but it is strong.

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, well-structured sentence that front-loads the core action (runs a bounded single-table SELECT) and then adds key constraints (no engine, closed grammar, error behavior). Every clause earns its place; 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?

Given the moderate complexity (3 params, no output schema), the description covers the key aspects: what it does, limitations, error handling, and how it relates to other tools. The rich schema covers parameter details, and the description adds the missing semantics about the SQL grammar and error reporting. It is complete for an agent to select and invoke correctly.

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

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 some context about the sql and query parameters being mutually exclusive, but the schema already describes each parameter well. The source parameter is intricate, but the description adds a helpful note about the extension not being used to infer formatched, which 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 runs a bounded single-table SELECT over an embedded .odb database's own extracted tables, either via SQL or a saved query. It distinguishes from siblings by explicitly contrasting with odb_tables and noting the closed grammar, which differentiates it from other odb-related 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 explicitly states the tool runs a bounded single-table SELECT over an embedded .odb database's own extracted tables, either via SQL or a saved query. It distinguishes from siblings by explicitly contrasting with odb_tables and noting the closed grammar, which differentiates it from other odb-related 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 provided, the description carries the transparency burden. It adds useful internal context by describing the data-bound command execution through the bounded SQL engine, formula evaluation, and band layout. However, it does not explicitly state whether the operation is read-only or whether the source .odb is modified, leaving side effects unaddressed.

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, information-dense sentence that front-loads the core action ('Resolves') and resource, then adds internal detail and output formats. It is not overly verbose, though the internal parenthetical elements make it slightly dense.

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 plus the extensive input schema and output schema cover report selection, source input (path or bytes), output destination (path or inline), and format-specific nuances (fonts only for pdf). Given the tool's complexity, the combined context is nearly complete, though an explicit statement on side effects would make it 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?

The schema already provides 100% parameter descriptions, including conditional requirements, source handling, output options, and format-specific notes. The tool description itself does not add significant parameter-level meaning, so 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 opens with the specific verb 'Resolves' and names the resource ('one of an .odb database's own reports'), then enumerates the output formats (docx, odt, pdf). This clearly distinguishes it from sibling tools like odb_reports, which likely only list reports, and odb_query, which executes queries.

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 and schema give clear context for when to use the tool: to render an .odb report to a document format. It details conditional behavior (e.g., 'report' optional when only one exists, fonts only for pdf). However, it does not explicitly name alternatives or state when not to use this tool (e.g., for tables/queries), so it falls short of the top score.

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 mentions what it returns but does not explicitly state whether it is read-only or any side effects, though it is implicit for a listing 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 concise and focused, with no unnecessary 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?

The description is sufficiently complete for a list operation, covering the parameter and return details, though it could be more explicit about usage 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 source parameter is well explained, including the union of path and bytesBase64+format, with clarification that format is not used for ODB, adding 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 lists reports in an ODB database and specifies the details returned (data-source command, band/group structure, rpt: formula expressions), distinguishing it from sibling 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 does not provide explicit guidance on when to use this tool versus alternatives such as odb_tables or odb_forms.

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, and it delivers: it discloses read-only enumerative behavior (lists), the output constituents (column names, types, row data), and, most valuably, the compatibility matrix across HSQLDB TEXT/CACHED/BINARY and Firebird gbak formats — the main behavioral complexity. It could have added performance caveats (e.g., row data volume) or return-structure details given no output schema exists, but for a benign listing tool the transparency is strong.

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 dense sentence with efficient front-loading: the action verb and object come first, followed by em-dash-delimited detail on return contents, and a parenthetical specifying the format scope. Every element earns its place; no filler or redundancy. Exemplary economy of language.

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 no output schema and no annotations, the description covers the key gaps: return contents (columns, types, data) and cross-format behavior. The parameter is handled comprehensively by the schema. The only deduction is for the cryptic 'storage tier documents.js supports' phrasing — an agent may not know what documents.js is or what a storage tier means without broader context, and a few words on return structure (per-table grouping?) would have completed the picture.

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 source parameter's hybrid path/bytesBase64 shape is documented exhaustively, including the subtle note that 'format' is required but unused for odb tools. Per the high-coverage baseline, the description need not repeat parameters, and it doesn't; the schema is the workhorse here. No additional parameter meaning in the description text itself, which 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 structure: 'Lists every table an embedded .odb database declares', with explicit detail on the output (column names, types, row data) and scope ('across every storage tier'). This clearly distinguishes it from siblings like odb_query (querying), odb_to_csv/odb_to_xlsx (format conversion), and odb_forms/odb_reports (document generation).

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 'across every storage tier documents.js supports' implies this is the comprehensive table-listing tool, and the format list (HSQLDB, Firebird gbak) gives contextual scope. However, there is no explicit when-to-use vs alternatives guidance, and given siblings like odb_query and odb_to_csv exist, explicit differentiation with named alternatives would have pushed this higher. Usage is implied rather than 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?

No annotations are provided, and the description does not disclose potential side effects, permissions, or error behavior. It only describes the extraction action, but does not explicitly state whether the operation is read-only or if it modifies the database.

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 that communicates the core functionality without extraneous details. It is front-loaded with the main action and includes a necessary conditional.

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, combined with the thorough schema, covers the main functionality and special conditions. It lacks explicit error handling or edge cases, but given the tool's simplicity and the schema's detail, it is sufficiently 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 provides complete descriptions for all parameters, including nested properties, and the tool description reinforces the requirement for the table parameter when multiple tables exist. The description adds context that ties parameters to the tool's behavior, but most semantic weight is carried by 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 purpose using the verb 'extracts' and specifies the resource 'exactly one named table from an embedded .odb database', as well as the output format 'CSV'. It distinguishes from sibling tools by focusing on CSV extraction.

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 a conditional usage note ('required whenever the database declares more than one table') but does not explicitly state when to use this tool over alternatives like odb_to_xlsx. It implies a single-table CSV use case but lacks 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?

No annotations are provided, so the description carries the burden. It mentions extraction and output format but doesn't describe side effects, permissions, or edge cases (e.g., behavior with no tables, handling of large files). It adds some value beyond the schema but lacks depth.

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 concise sentence that front-loads the purpose and includes the key detail about sheet-per-table. No fluff 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?

Given the tool's complexity (nested input, no output schema), the description adequately covers the main transformation. It could mention behavior with missing tables or output naming, but it's reasonably complete 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 coverage is 100%, and the description adds clarity around the source being an embedded .odb database and output being a workbook with sheets per table. It clarifies that 'format' is unused for odb tools, which is extra context 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 it extracts every table from an embedded .odb database into one xlsx workbook, one sheet per table. This is specific and distinguishes it from siblings like odb_to_csv or odb_tables.

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 is for exporting .odb tables to xlsx, but doesn't explicitly mention when to use it over alternatives like odb_to_csv or odb_query. However, the output format is clear from the name and description, providing adequate context for 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?

Since no annotations are provided, the description carries the full burden. It discloses the failure condition (unresolved chapters abort the conversion and list the missing hrefs) and the resolution order, which is non-obvious. It does not mention side effects or permissions, but the conversion context implies non-destructive 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, well-structured paragraph that leads with the core purpose, then explains the critical ODM quirk, and finally details resolution logic and failure mode. Every sentence contributes essential information with no filler, and the structure is logical and 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 the complexity of the tool (nested parameters, chapter resolution), the description fully addresses the key non-obvious behavior—chapter resolution—which is essential for correct usage. With a comprehensive input schema and an output schema present, the description does not need to elaborate on return formats or parameter details, making it 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 input schema already provides detailed descriptions for all parameters, including the resolution order and defaults, achieving 100% coverage. The tool description adds value by summarizing the overall flow and failure consequence, but it does not introduce new parameter-level semantics beyond what the schema already conveys.

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 begins with 'Converts a .odm (ODF master document) to PDF,' clearly stating the specific verb and resource. It further explains the unique structure of ODM files, distinguishing this tool from generic conversion tools like convert_document by emphasizing the chapter resolution mechanism.

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 tool is for ODM to PDF conversion by explaining the ODM-specific chapter handling. However, it does not explicitly mention alternatives like convert_document or state when not to use it, so it lacks explicit exclusion 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?

With no annotations provided, the description must disclose behavioral traits. It explains that the outline is over the source's own content, specifies the internal conversion target and its format limitations (pdf only for odf and odg), and details the return structure (groups and leaves). It does not mention performance or side effects, but the read-only nature is implied by 'projects' and 'reads the source,' which is sufficient.

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 paragraph that packs a lot of information, but it is quite long and includes implementation details (documents.js's DocumentConverter port, document-outline.js's buildOutline) that may be irrelevant to an agent. It is front-loaded with the main purpose, but the latter half becomes overly technical. It could be trimmed to improve conciseness while retaining key behavioral 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?

Given the tool has 1 parameter, no output schema, and no annotations, the description covers the essential aspects: what it does, how it processes the source, the output structure, and format-specific limitations. It does not explicitly list return values, but the structure is described. The description is sufficient for an agent 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?

The input schema covers the single parameter 'source' with 100% description coverage, detailing path or bytesBase64/format. The description adds semantic context by explaining that the document format is inferred from file extension or must be specified for inline bytes, and it clarifies the internal conversion target. Since schema coverage is high, the baseline is 3, but the description provides additional context about source handling and format nuances, earning a 4.

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: 'Projects a document's table of contents as a structured outline.' It identifies the specific source (a document), the action (outlining), and the output structure (groups with text, level, children; leaves with kind, text). This distinguishes it from siblings like convert_document and pdf_inspect, which serve different purposes.

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 this tool (when you need a structured table of contents or outline of a document). It also clarifies the internal conversion target: 'pdf only for odf (the one format that only converts to pdf) and odg (whose alternative, svg, cannot represent more than one page).' However, it does not explicitly say when NOT to use it or mention alternatives like pdf_inspect or convert_document.

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 burden of behavioral disclosure. It explains the output (summary vs full LayoutDocument) but does not mention side effects, permissions, or error behavior. As a read-only parse operation, side effects are minimal, but the description does not explicitly confirm safety or 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 two sentences, front-loaded with the core outcome, and every word adds value. No redundant information or 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?

Given the tool's simplicity (2 parameters, no output schema), the description adequately explains what the tool returns and how to get full results. It lacks discussion of error cases or performance limitations, but for a parsing tool with clear schema, this is nearly 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 100%, and the description adds value by clarifying the 'full' parameter's effect (return entire LayoutDocument instead of summary). The 'source' parameter is adequately described in the schema, and the description reinforces it. This exceeds the baseline for high-coverage schemas.

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 parses a PDF and reports a summary with specific components (page count, page sizes, item-kind histogram, metadata, image formats). It also distinguishes from sibling tools by focusing on inspection rather than conversion or manipulation.

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 usage context is implied: use this to inspect a PDF and get a summary. However, there is no explicit guidance on when to use it versus alternatives like convert_document or metadata_read. The description focuses on the full parameter but does not address when to choose this tool over others.

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