Darwin-owned Files

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

Annotations already declare the tool as read-only, idempotent, closed-world, and non-destructive. The description adds substantive transformation semantics not covered by annotations: one Data sheet, a SUM totals row, literal-string treatment of all other cells, no inferred formulas, and return of actual file bytes.

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

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

Three dense sentences with no wasted words. Output structure and the no-inference rule are front-loaded 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?

An output schema exists, so the description need not detail return values, but it usefully notes that actual file bytes are returned. Combined with annotations, the description is nearly complete for a three-parameter converter; the main remaining gap is the column-reference convention for numericColumns and totalColumns.

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 carry parameter meaning. It identifies the roles of numericColumns and totalColumns and implies that csv is the source, but it does not explain how columns are referenced (header names vs. indices), whether headers are required, or how numericColumns relates to totalColumns. It partially compensates but leaves meaningful ambiguity.

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

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

The description states a specific verb and resource — converting caller-supplied CSV into a real XLSX file — and adds concrete output structure (one Data sheet plus a SUM totals row). It is clearly distinguishable from siblings such as xlsx_to_csv, which performs the inverse conversion.

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 'exact caller CSV' and the requirement for explicit numericColumns/totalColumns imply when this tool is appropriate: when the caller controls the CSV and wants deterministic, non-inferred output. It does not explicitly name xlsx_to_csv or state when not to use this tool, but the format-conversion context makes selection 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?

Beyond the annotations, the description discloses real behavior: timezone resolution to UTC, refusal of ambiguous or nonexistent DST times, and the exact UTC ISO seconds format for createdAt. This is exactly the kind of error-condition and normalization detail an agent needs before invoking a converter.

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?

Dense but front-loaded: purpose first, then input format, then behavior and the negative-scope caveat. It packs a lot into a few clauses with little waste, though the single unbroken paragraph is slightly hard 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?

For a two-parameter converter with an output schema present, the description covers purpose, input grammar, timezone handling, failure modes, and the absence of calendar side effects. Nothing an agent needs to call it correctly is missing.

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

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

With 0% schema description coverage, the description must carry parameter meaning, and it does: eventBrief is decomposed into Start/Duration/Title components plus an optional Markdown heading, and createdAt's UTC-seconds requirement is stated. It stops short of describing edge cases like maxLength (131072) or what happens with malformed briefs.

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

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

The description opens with a specific verb+resource ("Create a real iCalendar file from a brief") and immediately details the exact shape of the input. It is clearly distinguished from the file-conversion siblings and from any tool that would actually place an event on a calendar.

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 scope statement "Does not add any calendar event" usefully clarifies that this only produces a file artifact, but the description never states when to pick this tool versus an alternative or what preconditions apply. Usage is implied by the detailed brief format rather than explicitly guided.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world; the description adds that the call is pure local rendering ("no fetches or external writes") and that output is inline file bytes plus a SHA256. That confirms the side-effect profile rather than restating it. Minor gap: no note on size or cost behavior for large inputs.

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

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

Three dense sentences, zero filler. The core purpose is front-loaded, with constraints and the return contract following in priority order.

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

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

For a one-parameter, zero-side-effect converter with annotations and an output schema, the description covers purpose, input restrictions, side-effect boundaries, and return shape. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 0%, so the description carries the burden and does: the single `markdown` argument is Markdown text, limited to a headings/paragraphs/lists subset and restricted to Windows-1252 characters. It doesn't mention the 131072-character cap, but that is visible via maxLength in 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?

Clear specific verb and transformation: "Render caller-supplied text Markdown to a real downloadable PDF," followed by the supported element subset and encoding limit. The resource is unambiguous and clearly distinct from the sibling converters (csv_to_xlsx, zip_text_files, etc.), though no sibling is named explicitly.

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 exclusions act as strong negative guidance: "No images, HTML, fetches or external writes" and "Windows-1252 text only" tell an agent exactly when this tool will not serve. It stops short of naming an alternative tool for unsupported inputs, so no explicit routing beyond the self-exclusion.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), and the description adds real behavior beyond them: formula values require pre-existing caches, formulas are not executed, and macros/external links/expansion bombs are refused. It also discloses that sheet names are preserved in metadata. Not a 5 only because it omits what happens on refusal (error shape) and the input size ceiling.

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

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

Three front-loaded sentences with no filler; the core action leads and edge-case behavior follows. Minor deduction for the vague qualifier 'genuine' UTF-8 CSV, which gestures at encoding details (BOM, quoting) without specifying them.

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?

An output schema exists, so return-value shape need not be described, and the description covers the important behavioral edges (formula caches, refusals, per-sheet splitting). The remaining gap is the input size limit and the failure mode when a workbook is refused.

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?

One parameter at 0% schema description coverage, so the description must compensate. It does clarify the encoding ('caller-supplied base64 XLSX'), which the schema only types as a bare string, but it never mentions the maxLength of 174764 (~128KB binary) — a hard constraint whose violation is a realistic failure mode and is documented nowhere else.

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

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

States a specific verb and resource ('Extract every sheet from a caller-supplied base64 XLSX into separate genuine UTF-8 CSV files') and makes the one-to-many sheet-to-file mapping explicit. That directionality cleanly separates it from the sibling csv_to_xlsx without needing to name 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 conversion direction is implied clearly enough that an agent can infer when to pick this over csv_to_xlsx, but the description never states a when-to-use condition or names the reverse-direction sibling as the alternative. Usage is inferable rather than instructed.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: it preserves bytes and nested safe paths, and rejects traversal, duplicate/colliding names, and excessive data. This tells the agent what input patterns will fail, which annotations alone do not provide.

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 dense sentences with no filler. The primary action is front-loaded, and the second sentence efficiently lists the behavioral constraints. Every phrase contributes useful information.

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

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

An output schema exists, so the description does not need to explain return values, and the annotations cover safety and idempotency. The description is nearly complete for calling the tool correctly: it explains input shape at a semantic level and rejection rules. It could be slightly more complete with explicit guidance on the maximum file count or size limits, but the schema already encodes those as maxItems and maxLength.

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 carry the semantic burden. It clarifies that each file has a caller-supplied 'name' and UTF-8 'text', that names may represent nested safe paths, and that path traversal and duplicate/colliding names are rejected. It does not mention the exact size/count limits, but the schema encodes those structurally and the description adds the important semantic constraints.

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

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

The description states a specific verb and resource: 'Create an exact ZIP of caller-supplied named UTF-8 texts.' It is immediately distinguishable from the sibling conversion tools (csv_to_xlsx, markdown_to_pdf, etc.) because it packages caller-provided texts into a ZIP rather than converting between file formats.

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

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

The description makes the usage context clear: the caller supplies named UTF-8 texts and no external files or fetches occur. It does not explicitly name alternatives or state when not to use this tool, but the 'No external files or fetches' exclusion gives strong guidance for an in-memory ZIP creation scenario.

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