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

With no annotations, the description must carry behavioral disclosure. It reveals key behaviors: free tier, 100 operations, prepaid balance, local storage, and that all other tools use the key. However, it omits critical details like whether this requires network access, if it's idempotent (calling again with a key already configured), or what happens on failure.

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

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

The description is front-loaded with key benefits but includes marketing-like pricing details that may be unnecessary for tool selection. The crucial instruction 'Call this once if no key is configured' appears last, which should be more prominent.

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 annotations, no output schema, and one optional parameter, the description covers the essentials but lacks some operational details. It explains key storage and usage but doesn't specify return value or error handling, which could be inferred but would be helpful.

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 the optional 'name' parameter. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate when 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?

The description states a specific action (create a free API key) and resource (bigapi API key). It is distinguishable from siblings like get_balance or get_pricing, though it overlaps with pricing information. The core purpose is clear.

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

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

Explicitly says 'Call this once if no key is configured,' giving clear when-to-use guidance. It does mention pricing context but doesn't detail alternatives for key management, which likely don't exist among siblings.

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

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

With no annotations, the description carries the full burden and does declare the key traits: it is 'Free and read-only', removing the risk of an accidental costly or mutating call. It stops short of stating rate limits or that the result is a point-in-time snapshot, but the safety profile is clearly conveyed.

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

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

Two sentences, both earning their place: the first enumerates what is returned, the second gives when to call plus the cost/safety profile. Information is front-loaded 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 parameterless, read-only status tool with no output schema, the description lists the fields the caller receives, which is exactly the context needed. 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the schema has no parameters to document.

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 ('Check the configured bigapi key') and enumerates the returned fields: remaining credit, free operations left, monthly cap, and spend this month. It does not explicitly distinguish itself from the similar sibling get_usage, so it stops short of a 5.

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

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

Gives explicit triggering conditions: call before large batch jobs or when an operation reports low balance. This is concrete prescriptive guidance an agent can act on directly, rather than implied context.

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

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

With no annotations, the description carries the full burden and does disclose two meaningful behavioral facts: the data is machine-readable and the endpoint is free with no API key required. It omits return shape and pagination, but the auth/no-cost disclosure is exactly the kind of context annotations would otherwise 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?

A single sentence with zero filler, and the key facts (what it returns, format, cost/auth) are front-loaded. Every clause earns its place.

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

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

For a zero-param tool with no output schema, the description specifies the payload contents (operations + price in cents) and access conditions, which is enough to call it correctly. Only the exact response structure is left unspecified, a minor gap given the simplicity.

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?

Zero parameters, so the schema contributes nothing to explain and the baseline is 4. There is no parameter meaning to add, and the description correctly does not invent any.

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 concrete resource (price list of bigapi.dev) and precisely defines its contents: every available operation with its price in US cents. That verb-plus-resource specificity lets an agent distinguish it from account-oriented siblings like get_usage, get_balance, and get_access.

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 usage context (checking operation costs) but never says when to call it versus alternatives such as get_balance or get_usage, nor any exclusions or prerequisites. Usage is inferable but not 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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the operation is free and read-only, and that results are grouped by operation type, but it omits authentication needs, rate limits, and return format or pagination details.

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

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

Two compact sentences with no waste. The scope and return grouping are front-loaded, followed by the read-only and cost-reporting context.

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-parameter read-only reporting tool with no output schema, the description adequately states the time scope, returned data, and read-only nature. It could still specify the exact return shape or timezone/month boundary, but it is largely complete for the tool's complexity.

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

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

The tool has zero parameters, and the input schema is empty. Per the rubric, zero parameters yield a baseline of 4, and there are no parameter semantics for the description to clarify.

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

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

The description names a specific resource and scope: this month's bigapi operations and their cost, grouped by operation type. It is clear what the tool returns, but it does not explicitly distinguish itself from siblings such as get_balance or get_pricing.

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

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

It gives a clear usage context: useful for cost reporting and audits. It does not state when not to use it or name alternative sibling tools, so it falls short of full when/when-not/alternatives 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 full disclosure burden. It conveys read-only intent ('Read') and helpfully discloses cost ($0.01), but says nothing about permissions, the file input source (path vs URL vs upload handle), or any limits. Adequate but with real gaps for a zero-annotation 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?

One tight sentence front-loads the returned fields, appends a usage hint, and closes with the price. Nothing is redundant and every clause earns its place.

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

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

For a simple single-parameter read tool with no output schema, the description adequately covers what is returned, why to call it, and its cost. The only material omission is the expected format of the 'file' argument.

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 a single 'file' parameter at 0% schema description coverage, the description must clarify what it accepts. The words 'image' and 'upload' hint at the target, but it never states whether 'file' is a path, URL, or upload reference, so the ambiguity is left unresolved.

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 (Read) plus the exact resource fields it returns (format, dimensions, color space, EXIF/ICC presence), making the operation unambiguous. It does not explicitly contrast itself with the nearest sibling image_process, but the read-only inspection framing differentiates it reasonably well.

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

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

Provides concrete when-to-use context ('to decide processing steps or validate an upload'), which orients the agent toward the inspection workflow preceding image_process. It stops short of naming exclusions or explicitly pointing to which sibling handles the actual processing, so it is clear context without routing.

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

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

With no annotations, the description carries the full burden. It usefully discloses cost ($0.01) and the destructive-ish default that EXIF is stripped unless keep_metadata is set, plus chainability. It omits auth/permission requirements, whether the source file is mutated, and what the response returns.

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 front-loads the operation list, then the chaining example and price. No filler, though the format enumeration could be trimmed since formats live in the schema enum.

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 14-parameter tool with no annotations, no output schema, and 14% schema coverage, the description covers the operation set and cost but leaves the return value, file input expectations, and several parameters unexplained. 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 only 14%, so the description must compensate. It loosely maps operations (resize, crop, rotate, convert, quality, watermark) to parameters and lists formats, but ignores fit, output_path, idempotency_key, and the watermark_gravity/opacity knobs, and even omits gif from its format list.

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 specific verbs (resize, crop, rotate, convert, compress, strip EXIF, watermark) applied to a specific resource (an image), and the chaining behavior is explicit. This clearly distinguishes it from the read-only sibling image_info.

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

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

Provides a concrete usage example ("resize to 1200px, convert to webp, quality 80") that shows how to express multi-step intent in one call. It does not name alternatives or exclusions (e.g., when to prefer image_info first, or when to just call a single operation), but the context is clear.

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

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

No annotations exist, so the description carries the burden and does well: it discloses which Markdown constructs survive conversion, that the return is a local output path, and a $0.01 cost. It omits error/overwrite behavior when output_path already exists and any size limits, which keeps it from a 5.

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

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

One dense sentence, front-loaded with the core transformation, then return behavior, then cost. No filler and nothing buried.

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

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

With no annotations and no output schema, the description must carry the full load; it covers output form and pricing but leaves two of three parameters undocumented, which is a meaningful gap for a 3-param 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 0% for all three parameters, so the description must compensate and does not: output_path (presumably the destination file) and idempotency_key (presumably dedupe/retry safety) are never explained. Only the markdown input is implicitly covered.

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+resource (Markdown → formatted .docx) with format details, and no sibling competes for that conversion (siblings cover pdf_*, office_to_pdf, pdf_to_markdown). An agent can select it unambiguously.

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?

"e.g. an answer you just wrote" gives a concrete usage context that routes the agent to this tool. However, no when-not conditions or explicit alternatives are named, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose the default output format, the accepted language-code syntax, and a concrete cost model ($0.01 per page). It omits failure behavior, whether output_path must exist, and file size limits, so it is not fully complete, but the cost and format disclosure is substantially more than most.

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

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

Three tight sentences, front-loaded with the action and formats, with the usage trigger and cost clearly placed. Minor density around the language-code example, but no wasted sentences.

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 six-parameter, no-annotation, no-output-schema tool, the description covers purpose, trigger, formats, language codes and cost, but leaves the semantics of output_path and idempotency_key unexplained and gives no return-value shape. 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 coverage is 0%, so the description must compensate. It explains lang format ('deu+eng') and the output enum values, but says nothing about dpi, output_path, or idempotency_key, leaving three of six parameters undocumented in both schema and 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 (turn into), a specific input (scanned PDF or photo of a document at a local path), and the three concrete output formats. This clearly separates it from siblings like pdf_to_markdown or pdf_extract_tables, which assume an existing text layer.

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 condition: 'Use whenever a PDF has no extractable text layer.' That is a real decision rule an agent can apply. It stops short of naming alternatives or when-not-to-use, but the condition is strong enough to route 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?

With no annotations, the description carries the full burden, and it does disclose genuinely useful traits: server-side LibreOffice execution ('no Office installation needed anywhere') and a per-page cost of $0.01, which matters for planning. It says nothing about output behavior (where the PDF lands, whether output_path is created/overwritten) or auth, so gaps remain.

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?

It is a single dense sentence plus a short pricing clause, front-loaded with the core verb and format list. The parenthetical format enumeration is long but earns its place; nothing 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?

For a tool with no annotations, no output schema, and 0% parameter documentation, the description should say more about outputs and the two undocumented parameters. It adequately covers the input document and cost but leaves the return value and output_path/idempotency_key semantics unexplained.

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% on three parameters, so the description must compensate. It clarifies that 'file' is a local path and implicitly which formats are valid, but 'output_path' and 'idempotency_key' receive no explanation at all, leaving two of three parameters undocumented.

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 gives a specific verb+resource ('Convert an Office document ... to PDF') and enumerates all accepted input formats, so the agent knows exactly what the tool consumes and produces. It also names the underlying mechanism (server-side LibreOffice), which disambiguates it from generic renderers like 'render'.

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 only implied by the format list and the phrase 'local path' — there is no explicit when-to-use statement, no when-not, and no routing to alternatives such as 'render' or 'md_to_docx'. The agent must infer the boundary itself.

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 present, so the description carries the full behavioral burden. It usefully discloses cost ($0.01), the default compression level, and the size/quality tradeoffs of each level, but it omits whether the original file is overwritten, how output_path is used, permission/payment requirements, and idempotency 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?

Front-loaded with the core action, followed by a concrete use case, level guidance, and price. It is compact and every sentence earns its place.

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

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

With no annotations, no output schema, and 0% schema description coverage, the description should do more. It covers the main operation, cost, and level semantics, but omits output file behavior, idempotency key semantics, and return information.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It explains the 'level' enum values and default well, but leaves 'file', 'output_path', and 'idempotency_key' undocumented, so it only partially compensates.

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

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

States a specific verb and resource: 'Shrink a PDF's file size.' The goal is unmistakable and distinguishes it from sibling PDF tools like pdf_merge, pdf_split, pdf_rotate, and pdf_to_pdfa.

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 use case ('to fit e-mail attachment limits') and guidance for each level, including the default and quality tradeoffs. It does not explicitly compare against alternative tools or state when not to use this tool, 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?

With no annotations, the description carries the full burden. It usefully discloses cost ('$0.01 PER PAGE') and the default output format, which are real behavioral traits. But it omits any indication of auth/permission needs, processing time, or what happens on non-text PDFs (failure mode), so coverage is partial.

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

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

Two tight sentences, front-loaded with the action and output, then use cases, then the cost signal in caps. Every clause carries information; nothing is 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?

Covers purpose, output format, and pricing well, and there is no output schema to explain. But for a 7-parameter tool with near-zero schema documentation, the pagination params, output_path, and idempotency_key are left entirely to inference, leaving the definition incomplete for correct invocation.

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

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

Schema description coverage is only 14% – essentially just min_cols is documented in the schema. The description compensates only for the output enum (JSON/CSV) and the 'local path' nature of file; first_page, last_page, output_path, idempotency_key and min_cols remain unexplained, which is a significant gap for a 7-param tool.

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+resource ('Find tables in a text-based PDF') and the output form ('JSON rows (default) or CSV'). The 'text-based PDF' qualifier implicitly separates it from OCR-based siblings, and it names concrete use cases (invoices, reports, bank statements). It stops short of naming an explicit alternative tool, so not a 5.

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

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

The 'text-based PDF' framing implies that scanned/image PDFs need a different tool (e.g. ocr), and the listed document types sketch a usage context. However there are no explicit when-to-use/when-not statements and no alternative tool is named, leaving the routing inference to the agent.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the cost ($0.01), the local-path input constraint, and the lightweight/cheap nature of the call. It does not say what happens on encrypted or malformed PDFs, nor whether the metadata call fails or degrades, leaving a real gap for a read tool with zero annotation coverage.

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 tight sentence that front-loads the verb and resource, then the field list, then the cost. Every clause earns its place 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?

No output schema exists, and the description enumerates the returned fields adequately for an agent to know what comes back. The local-path constraint and cost cover the main call-time decisions; only error/encryption-edge behavior 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?

Schema coverage is 0% and the single 'file' parameter is undocumented in the schema. The description compensates by specifying '(local path)', which tells the agent this is a filesystem path rather than a URL or ID — meaningful semantics beyond the bare string type.

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?

Specific verb (read) plus resource (PDF metadata) with an explicit enumeration of the returned fields (page count, title, author, PDF version, page size, encryption and form flags). It is clearly distinguishable from siblings like image_info, render, or pdf_merge, which act on content rather than metadata.

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

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

States the usage context plainly: 'a cheap first check before more expensive processing,' which tells the agent to probe with this before invoking heavier siblings like pdf_to_images or ocr. It does not name those alternatives or state exclusions, so it falls short of a full 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, the description carries the full behavioral burden. It usefully discloses that inputs are local paths, that order is preserved, and that the call costs $0.01, but says nothing about whether an existing output file is overwritten, where output lands by default, retry/idempotency behavior, or permission needs.

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 sentence that front-loads the action and ordering constraint, then adds selection examples and the price. Nothing is padded or 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?

For a three-parameter, no-annotation, no-output-schema tool, the description covers purpose, ordering, and cost but leaves the destination of the merged file and the idempotency contract unaddressed. Adequate but with clear gaps an agent would have to infer.

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 only 33% – only 'files' is documented. The description reinforces that param (local paths, order preserved, minimum of two) but neither output_path nor idempotency_key is explained anywhere, and idempotency is materially important for a paid operation.

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?

Starts with a specific verb+resource ('Merge two or more PDF files ... into a single PDF') and states the ordering guarantee. An agent can distinguish it from pdf_split, pdf_compress, and pdf_rotate purely from this sentence.

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?

Three concrete use cases (combine chapters, append attachments to an invoice, assemble a report from parts) tell the agent when this tool applies. It stops short of naming the inverse sibling (pdf_split) or stating when-not to use it, so it is clear context without explicit alternatives.

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

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

With no annotations, the description carries the full burden. It usefully discloses default page scope and a $0.01 cost, but says nothing about whether the operation overwrites the source file, whether output_path is required to persist results, or what idempotency_key does — all relevant for a file-mutating 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?

Two tight sentences with zero filler: the capability and its accepted values come first, the use case second, and scope/cost are appended. Nothing is repeated or padded.

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 5-parameter mutation tool with no annotations and no output schema, the description leaves two parameters (output_path, idempotency_key) and the entire return/write behavior unaddressed. What an agent needs to call this correctly — especially where the rotated file ends up — is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real value for pages ('All pages by default, or a range like "2-4"'), clarifying the '1-z' default, but output_path and idempotency_key are entirely unexplained in both schema and description, and the angle values merely restate the enum.

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+resource (rotate PDF pages) with the exact accepted values (90, 180, 270) in the first clause. It is unambiguously distinct from siblings like pdf_merge, pdf_split, or pdf_compress, so an agent can select it 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 a concrete motivating scenario ('to fix sideways or upside-down scans') and states the default scope (all pages), which tells the agent when this tool applies. There is no sibling alternative to route away from, so the absence of explicit exclusions costs little.

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 usefully discloses the cost ('$0.01') and the default full-range behavior via the '1-z' default, but omits mutation-side behavior such as whether output_path is overwritten, what happens on out-of-range pages, or any permission requirements.

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

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

Two sentences, front-loaded with the core action, followed by the parameter syntax and pricing. Efficient and free of filler, though the trailing '$0.01' reads as an appended tag rather than integrated information.

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

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

With no output schema and no annotations, the description should say more about the produced artifact and remaining parameters. It covers page selection well but leaves the idempotency key, output_path defaults, and result/file-location behavior unexplained for a paid, file-producing tool.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains the 'pages' parameter syntax and its default semantics ('1-z', 'z = last page'), which is a real value add, but 'file', 'output_path', and especially 'idempotency_key' remain undocumented in both schema and 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+resource+output ('Extract pages from a PDF into a new PDF'), which cleanly separates it from pdf_merge (combines), pdf_rotate, and pdf_compress in the sibling list. An agent can select it 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?

The page-expression examples ('1' for first page only, '2-z' to drop a cover sheet) give task-oriented context, which implies usage. However, it never states when to prefer this over siblings like pdf_merge or when splitting is inappropriate, so guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It usefully discloses output-shape branching (single page → image file, multiple pages → ZIP) and cost ($0.01), which are genuine behavioral traits. However, it omits error behavior, idempotency_key semantics, output_path behavior, and any hints about determinism or limits.

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

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

Three tight sentences with the core action and output behavior front-loaded; every clause carries meaning. The parenthetical dpi guidance partially duplicates schema defaults, preventing a full 5.

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

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

Given no output schema, the description helpfully explains the return shape (image file vs ZIP) and cost, and covers the highest-impact parameters. The remaining gap is the unaddressed non-obvious params (quality, output_path, idempotency_key) in a tool where none of the 8 params are documented anywhere else.

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

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

Schema description coverage is 0%, so the description must compensate. It explains format (JPEG default, PNG), dpi (150 default, 300 for fine detail), and page range, but leaves quality, output_path, and idempotency_key unaddressed beyond whatever the parameter names imply.

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?

Names a specific verb (render) and resource (PDF pages → JPEG/PNG images), plus the concrete use cases (feeding a vision model, previews/thumbnails). An agent can distinguish it from siblings like render, screenshot, ocr, and pdf_to_markdown without opening a 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 clear when-to-use context (vision model input, previews/thumbnails) which orients the agent well. It stops short of naming alternatives or exclusions (e.g., versus render, screenshot, or ocr), so routing between similar tools is still partly inferential.

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 must carry the behavioral load, and it does disclose meaningful traits: the output transformation (reflow, hyphenation, page separators) and a concrete cost model ('$0.01 PER PAGE'), which matters for large PDFs. It omits auth/permission requirements, error behavior, and idempotency/repeat-call behavior, so it falls short of fully covering a no-annotation mutation-adjacent 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?

Three tight sentences, front-loaded with what the tool produces, followed by use cases, the OCR caveat, and the price. Each sentence earns its place; nothing is restated from the schema or title.

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

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

With 7 parameters, no output schema and no annotations, the description is complete on purpose, cost and OCR routing but silent on page-range extraction, output destination, and idempotency-key usage. An agent can call it for the basic case but lacks guidance for the pagination and file-writing options the schema exposes.

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 only 29% – file, first_page, last_page, output_path and idempotency_key carry no descriptions. The prose partially compensates by explaining the reflow-vs-layout behavior and that output is Markdown text, but it never mentions pagination ranges, the output_path destination, or idempotency, leaving most parameters unexplained.

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+resource ('Extract the text of a PDF ... as clean Markdown') and goes further by naming the transformation guarantees (reflowed paragraphs, resolved hyphenation, page rules). It also distinguishes itself from the OCR sibling by noting scanned PDFs need ocr first, so an agent can tell it apart from pdf_to_images, pdf_extract_tables and ocr without opening a 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?

Explicitly frames intended uses (summarising, RAG ingestion, further processing) and gives a clear exclusion with a named alternative: 'Scanned PDFs need ocr first.' That is the when, the why, and the routing rule in two sentences.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the output variant (PDF/A-2b), font embedding, and the cost ('$0.01'), but says nothing about where output is written by default, whether existing files are overwritten, or how errors are reported for a tool that produces a new artifact.

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

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

A single front-loaded sentence that packs purpose, format, target use case, and cost with no filler. Every clause earns its place.

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

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

No annotations, no output schema, and only one of three parameters explained. For a file-mutating conversion tool the agent still lacks output location, idempotency semantics, and return-value information, leaving meaningful 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 0% for all 3 parameters, and the description only clarifies one of them ('local path' for file). output_path and idempotency_key are left entirely undocumented in both schema and description, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Convert a PDF ... to archival PDF/A-2b with embedded fonts') with the exact target format and an input-location constraint ('local path'). This clearly separates it from siblings like office_to_pdf, render, or pdf_compress.

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 usage context ('required for long-term storage and legal/tax compliance workflows'), which tells the agent when this tool is the right choice. It does not name alternatives or state when not to use it, 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?

No annotations are provided, so the description carries the full burden. It does disclose useful behavior: server-side Chromium rendering, that it returns the local output path, and a $0.01 cost. It omits permissions/auth requirements, execution timing, size or input limits, and error behavior for a 14-parameter 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 core capability is front-loaded in the first clause, which is good. But 'pixel-perfect', 'the reliable way to produce polished documents', and the parenthetical document-type list are promotional filler that does not help an agent invoke the tool, diluting an otherwise compact definition.

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

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

With 14 parameters, no annotations, and no output schema, the description does the minimum: it names return value ('local output path') and cost. It does not clarify defaults, mutual exclusivity of html/markdown/url, or how output_path interacts with format, leaving meaningful gaps for a tool of this complexity.

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

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

Schema coverage is only 50% across 14 parameters. The description conveys format choice (PDF/PNG), page formats A4/A3/Letter/Legal, CSS support, and the page-number footer, but leaves margin_mm, landscape, png_width/png_height/png_full_page, output_path defaults, and idempotency_key entirely to the schema. It compensates for only a small share of the uncovered parameters.

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

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

States a concrete verb (render) with explicit inputs (HTML, Markdown, public URL) and outputs (PDF default or PNG), plus the mechanism (server-side Chromium). This clearly separates it from siblings like screenshot or office_to_pdf without needing to open 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?

Implies usage via 'the reliable way to produce polished documents... without a local browser or PDF library' and lists document types, which signals when it is appropriate. However it never names alternatives (e.g. office_to_pdf for Office files, screenshot for page images) or states when not to use it, so routing remains inferential.

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 and discloses several useful traits: only public URLs, full-page default, an optional delay for late-loading content, the return being a local output path, and the $0.01 cost. It stops short of auth requirements, overwrite behavior for output_path, or rate limits.

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

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

Two compact sentences with the capability front-loaded and the use cases and cost trailing appropriately. The trailing '$0.01' is slightly abrupt but earns its place as cost disclosure.

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 an 8-parameter tool with no annotations and no output schema, the description covers the primary use and return shape but leaves output_path, idempotency_key, format, and quality semantics unexplained. Adequate but not complete for the tool's complexity.

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

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

Schema coverage is only 25% (quality and delay_ms only), so the description compensates partially by naming the device presets, the full-page default, and the delay option. However it says nothing about output_path, idempotency_key, or format/quality interplay, leaving several parameters undocumented in both places.

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+resource (screenshot a public URL) and the scope (device presets, full page by default), which cleanly separates it from text-extraction siblings like url_to_markdown. An agent can tell what it produces (an image of a page as a browser sees it) without opening the schema.

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

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

It lists intended scenarios (visual checks, monitoring, documentation, archiving), which implies when it is useful, but never contrasts with alternatives such as url_to_markdown or render, nor states when it should not be used. Usage is implied rather than routed.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a genuinely useful behavioral trait, that the new cap applies from the next operation rather than retroactively, plus the default value. However, it says nothing about permissions needed, whether the setting persists, or what happens when the cap is hit, leaving notable gaps for a mutation 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?

Three short sentences, front-loaded with the core action and unit, followed by usage context and timing. Every sentence adds information 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 mutation with no annotations and no output schema, the description covers units, default, rationale, and effective timing. It is nearly complete, though it omits what enforcement looks like once the cap is reached.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it names the unit (US cents), the default (1000 = $10), and a scaling example (5000 = $50). The schema's min/max bounds (0–1000000) are not restated, but the essential semantics of the single parameter are well covered.

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 (set) and resource (monthly spending cap of the bigapi key) with the exact unit of measurement. It is trivially distinguishable from sibling tools like get_usage or get_balance, which are read operations on related concepts.

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 when-to-use context: raise before large batch jobs, lower to guard against runaway loops. It does not name an alternative tool or state exclusions, but for a single-purpose setter there is no obvious sibling to route to.

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

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

With no annotations, the description carries the full burden. It usefully discloses JS execution, the Markdown output shape, and the $0.01 cost, but says nothing about failure modes, timeouts, size limits, or how JS-heavy/blocked pages behave.

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 tightly packed sentence that front-loads the mechanism and output format, then adds purpose and price. 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?

No output schema and no annotations, and an 8-parameter surface with only half documented. The description covers what an agent needs to know about the result and cost, but leaves parameter behavior and error conditions partly unaddressed.

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?

Only 50% of the 8 parameters are described in the schema; wait_until, output_path, idempotency_key and url carry no documentation there. The description adds nothing about timing controls or output destinations, and its 'return it as Markdown' phrasing sits awkwardly against the default output=json mode.

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 (fetch), resource (public web page), mechanism (real browser with JavaScript) and output (GitHub-flavoured Markdown with absolute links and tables). This is far more precise than the sibling pdf/render/screenshot tools and an agent can tell what it produces without opening the schema.

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

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

Names concrete use cases (reading, summarising, archiving pages as text) and scopes the tool to 'public' pages, which implicitly rules out authenticated content. It never names an alternative sibling (e.g. screenshot for visual fidelity, render for full-page capture), so routing is inferred rather than stated.

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