ReflowPDF

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the interaction model (the client shows a Connect button), the session effect (once signed in, every call is that account's), and the guest fallback. It stops short of covering repeat invocation, already-signed-in state, or failure modes.

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

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

What the tool does is front-loaded in the opening clause, and the benefit, mechanism, session effect, and guest fallback follow in short sentences. Slight wordiness in the closing guest-mode sentence, but nothing is redundant.

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 zero parameters, an output schema, and annotations covering the safety profile, the description carries only the behavioral burden and mostly meets it. The main gap is what a caller should do if the person is already connected or declines.

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 takes no parameters, so the baseline applies; there is nothing for the description to disambiguate. It correctly implies the only input is a user action in the client rather than arguments.

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

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

The description names a concrete verb and resource: it signs the person in to their ReflowPDF account, and it is distinct from every document-handling sibling. It does not explicitly say how it differs from those siblings, but the account/session framing makes its role unambiguous.

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

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

It states exactly when to use it: when the person wants unmarked PDFs, their plan's page allowance, or documents persisted in their account. It also names the alternative and its cost - everything works as a guest, but with a small mark - so the agent can weigh use vs. skip.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the document may have been edited by the recipient and the returned state reflects current editor content, not the original render. It stops short of noting authorization or scope limits, but with an output schema present that is a minor gap.

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

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

One density-loaded sentence followed by a short imperative directive; the core purpose and the current-state caveat are front-loaded. The main sentence is long enough that the third clause ('its source HTML, template data and revision') requires a second pass, but there is no 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?

With one required parameter, an output schema, and annotations covering the read-only profile, the description carries everything an agent needs to call it correctly and explains why freshness matters. Only the sibling boundary against get_template remains implicit.

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 schema itself explains that document_id may be the ID or the edit link from render_pdf, render_template, or open_in_editor. The description's phrase 'opened in the editor from your link' reinforces this but adds no new format or syntax detail. Baseline 3 is correct when 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 ('Returns a document made with ReflowPDF... as it is now') and scopes it to documents the caller made or opened via an edit link. It also enumerates the returned payload (source HTML, template data, revision), which separates it from get_template and list_templates at a glance.

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

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

It gives an explicit sequencing rule — 'Read it before changing it with update_document' — which names the alternative and the condition selecting it. However, it does not explain when to use get_document instead of get_template, which is the other plausible sibling for document-like content.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the content shape (source plus sample data), but says nothing about payload size, template provenance, or failure modes for a bad id — and the existence of an output schema further reduces what the description needs to carry.

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

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

One front-loaded sentence with the return content first and the two intended uses after; no filler or restated title verbosity.

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 an output schema present and all parameters documented, the description only needs to convey purpose and next step, which it does. Coverage of edge cases (nonexistent id, template size) is the only remaining gap.

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

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

Schema coverage is 100% and the single 'id' parameter already documents its origin ('from list_templates'), so the description adds no parameter meaning beyond the schema. Baseline 3 is appropriate for a one-parameter tool whose schema does the work.

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 ('Returns a gallery template's source and its sample data'), which is far more informative than the name alone and separates it from read-style siblings like get_document. It implies but does not explicitly state the split versus list_templates (which merely enumerates ids).

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

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

Gives concrete downstream contexts — use the result with render_template to fill in a person's values, or adapt it into your own template — which tells the agent why and when to fetch a template. It stops short of naming an explicit alternative or a 'do not use when' condition.

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

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

Adds substantial behavior beyond annotations: the returned link expires after 24 hours, native ReflowPDF files open from their own source immediately, other PDFs are rebuilt by AI, require a free account, consume AI pages, and display cost in the editor. This is exactly the kind of operational context annotations 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 key outcome and link validity are front-loaded, and each subsequent sentence contributes necessary operational detail about source PDFs, AI rebuilding, cost, and input options. No filler.

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

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

For a complex import operation, the description covers the return link, expiry, rebuild behavior, account requirement, cost visibility, and input forms. Since an output schema exists, it need not explain the response object further.

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

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

Schema description coverage is 100%, so the schema already documents url, name, and pdf_base64 including the 20 MB base64 limit. The description reinforces that the URL must be public https and that base64 is for small files, but adds little beyond what the schema provides.

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

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

States a specific verb and resource ('import a PDF', returns a link that opens it in the editor's import and rebuilds it as editable) and explains the two rebuilding paths. An agent can understand what this tool does without opening the schema, and it is distinguishable from simpler document-open 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?

Gives clear context for use: a public https URL or base64 bytes for small files, plus the consequence that non-native PDFs need a free account and consume AI pages with cost shown first. It does not explicitly compare against siblings or state exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully adds that entries are templates 'with sample data', but says nothing about result caps, ordering, or what an empty result means, and there is no annotation about result size.

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?

Only two sentences, but the long enumeration of document types (invoices, quotes, receipts, statements ... tickets, labels, menus) consumes most of the budget and largely restates the category enum in the schema. The core distinction — catalog listing versus a single template — is not front-loaded.

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

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

For a zero-required-parameter, read-only listing tool with an output schema and annotations, this is close to sufficient: the agent knows what comes back and that it is safe. The remaining gap is how the two filters interact and whether results are paginated or truncated.

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 both parameters are documented in the schema, so the schema does the heavy lifting. The description's inline examples ('invoice', 'contract') give mild additional intuition for the query string but duplicate the purpose already stated in the schema field description.

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 ('Lists the gallery's ready documents ... each a template with sample data'), so the agent knows this returns template catalog entries rather than document instances. It never names or contrasts with the sibling get_template, so an agent facing both still has to infer which one returns a single template.

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 closing sentence ('Search by a word ... or a category') implies the two usage modes but frames them as mechanics rather than when-to-use guidance. There is no statement about when to call get_template instead, or whether both filters can be combined.

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 mark it as non-readOnly and non-idempotent with no destruction; the description goes beyond that by explaining the collaboration model and that template content is preserved as editable template+data rather than flattened. It omits whether each call creates a distinct editor document (relevant given idempotentHint=false), which is the main residual gap.

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

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

Short and front-loaded, leading with the return value and the person-edits context before the usage cue. The nested parentheticals make it slightly dense, but no sentence is wasted.

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 an output schema covering the edit link and full schema descriptions, the description only needs to convey the collaboration model and template/data semantics, which it does. The missing piece is what happens on repeated calls or what preconditions (auth/account connection) are expected.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it clarifies that the HTML path versus the template-with-data path are alternatives, and that data stays editable alongside the template. It does not clarify how name or template_id interact when several parameters are supplied together.

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

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

States a specific action and object: it returns the edit link of a document in the ReflowPDF editor, and clarifies the human edits it on the page and downloads it. That distinguishes it from siblings like render_pdf or get_document, though the 'open' in the name could still be misread as an action the agent performs.

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

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

Gives an explicit trigger: 'Use when the person wants to change the document themselves,' and points to the complementary path (you can edit via get_document/update_document). It does not state when *not* to use it (e.g., when the agent should just call update_document directly), so it falls short of a 5.

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

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

The readOnlyHint and openWorldHint annotations already establish that this is a safe, local read operation. The description adds useful topic coverage, but it does not disclose the return format, whether the guide is static, or any other behavior beyond what annotations 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 a single front-loaded sentence with zero filler; every parenthetical item maps directly to an enum value and helps topic selection. It is appropriately sized for a one-parameter documentation lookup 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?

The description fully covers the only parameter and all of its possible topics, which is the main complexity for this tool. It does not state the return format, but with read-only annotations and a simple enum parameter, most of what an agent needs is present.

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 would be 3, but the description goes beyond the schema by explaining what each enum value contains, such as "pages" covering page kinds, breaks, covers, and bleed/crop marks. This materially helps an agent choose the correct topic.

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

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

The description identifies the resource as "The engine's guide" and enumerates what each guide topic covers, making clear that this tool retrieves documentation. It is distinguishable from sibling tools like get_document or render_pdf, though it never states the retrieval verb explicitly or names 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?

Usage is implied: read this guide to learn how to write ReflowPDF documents, with topics mapping to specific authoring concerns. There is no explicit when-to-use guidance, no prerequisites, and no mention of when not to use it versus 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?

Adds substantial context beyond annotations: the download link expires in 24 hours, JavaScript does not run, and the response contains two links that must both be surfaced. Annotations already cover the safety profile (openWorld, non-idempotent, non-destructive), and the description complements them rather than contradicting. It stops short of stating explicitly that each render creates a new persistent document, which the 'edit link' and update_document reference only imply.

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

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

Front-loaded with the core action and outputs, then prerequisites and authoring hints. Every sentence carries distinct information (outputs, expiry, CSS technique, JS limitation, prerequisite reading, follow-up tool) 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?

Even though an output schema exists, the description explains the practical return values (two links, 24h expiry) and the preview/filename defaults are covered in the schema. Prerequisites, follow-up path, and CSS authoring constraints are all present, so an agent can call this correctly on the first attempt.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning about the html parameter's required shape (@page for paper and margins, margin boxes for headers/footers/page numbers, no JavaScript) and clarifies that both returned links should be given to the user. This is guidance the schema alone would not supply.

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 ('lays out a whole HTML document ... as paged print') plus the concrete output (a PDF download link valid 24 hours and an editor edit link). It also distinguishes itself from siblings by naming update_document for later edits and read_guide for prerequisites.

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 tells the agent to read read_guide topic "html" before the first document, and to use update_document with document_id for subsequent changes rather than re-rendering. The 'give the person both' instruction and the @page/margin-box guidance define how to use it correctly.

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?

Goes well beyond the annotations by disclosing outputs and lifecycle: a PDF download link valid 24 hours, an editable editor link, and the state transition where editing on the page converts it to plain HTML. The closing clause 'then change its html' is ambiguous — no such parameter exists in the schema — which slightly muddies an otherwise strong disclosure. With readOnlyHint=false and non-idempotent already declared, the mutation framing is consistent, not contradictory.

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 with purpose and dense with useful facts, but the middle sentence is a long run-on with nested parentheticals that takes effort to parse. Nearly every clause earns its place; the phrasing could be tightened without losing content.

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 and the description still summarizes the returns (links, editorship expiry), and it covers the input-source decision, so an agent has what it needs to call correctly. The dangling 'change its html' reference points at a tool or field not identified, leaving one loose end in an otherwise complete definition.

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 schema already documents data, preview, filename, template and template_id; baseline would be 3. The description adds genuine value on top by stating the mutual exclusivity of template vs. template_id and the 'no data prints the sample' default, which the schema does not say.

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 ('Fills a template with JSON data and prints it to PDF') and immediately scopes it against the sibling render_pdf by naming the template/gallery inputs it accepts. An agent can tell this apart from list_templates or get_template without opening any schema.

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

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

Gives explicit routing: use template_id from list_templates, get sample data shape via get_template, and read the 'templates' guide topic via read_guide. It also spells out the two mutually exclusive modes (gallery template vs. own source) and the fallback behavior when data is omitted, so when-to-use is fully determined.

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

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

Adds substantial behavior beyond annotations: new-version semantics, automatic reprint, returned PDF/edit links, and optimistic concurrency refusal when the person changed the document. This directly complements readOnly=false/idempotent=false and does not contradict destructive=false.

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

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

Single dense paragraph, front-loaded with the action and output; the example and concurrency warning earn their space. A few clauses are packed, but it is appropriately sized for a complex mutation.

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 complex mutation with rich schema and output schema, the description covers the essential edit flow, required source revision, template data handling, and returned links. Remaining details like preview and filename behavior are fully documented in the schema.

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

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

Schema coverage is 100%, so baseline is 3, but the description clarifies that html must be the whole new source and base_revision is the read revision, and explains stale refusal. It adds workflow meaning beyond the schema, though it leaves name/filename/preview to 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 title and first clause state a specific mutation ('Writes a new version') on a specific resource ('document by its link'), and the example scopes it to edit requests. It references get_document for the source revision, but does not explicitly contrast with render_pdf or open_in_editor.

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

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

Gives a concrete chat-request trigger and a required read-then-write workflow: change what get_document returned and pass base_revision. It also states the stale-revision refusal and instructs to read again, though it does not enumerate alternative 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?

Beyond the annotations, it discloses the returned value (a link), supported formats, the 10 MB size ceiling, and 30-day retention tied to a document's last change. These are operational constraints and lifecycle details the annotations do not provide, and nothing conflicts with readOnly=false/openWorld=false/idempotent=true.

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 definition is front-loaded with what the tool does and why use it over a data: URI, then proceeds through size, alternatives, SVG, and retention. Each sentence carries a distinct, useful constraint or routing rule, with no filler.

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

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

For a one-parameter upload tool with an output schema, it covers the missing context an agent needs: link return, format and size limits, retention, and the main alternatives. Nothing needed to call it correctly is absent.

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

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

The single parameter has 100% schema description coverage, so the baseline is 3. The description adds value by clarifying that the payload is base64 text for small images and by setting formats and a size limit; the schema itself covers the data: URI acceptance detail.

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 first sentence names a specific action (keeps/upload image bytes) and resource (image) and states the concrete result: a link for <img src> or CSS url() in named sibling tools. It also distinguishes itself from data: URIs and from public-URL or human-provided images, so an agent can separate it from the listed 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?

It gives explicit use conditions ('bytes you have', 'small images') and alternatives: ask the person to add their image in the editor and use get_document, use a public https address directly, or inline SVG as HTML. The tool's role relative to render_pdf, render_template, open_in_editor, and update_document is explicit.

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