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

Beyond annotations, the description discloses the permanent/destructive nature of the operation, the ability to stage before applying, and that it reads/writes locally or from sandbox. It does not contradict annotations. Adds context on types of content detected and default behavior when neither stage nor apply is set.

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

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

The description is well-structured with a clear opening sentence, bullet points for content types, and clear paragraphs for stage/apply workflow. Every sentence adds value, no fluff. Appropriate length.

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

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

Given the tool's moderate complexity and lack of output schema, the description covers the essential aspects: what it does, parameters, workflow, and file handling. It is sufficient for an AI agent to understand when and how to use it effectively.

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. The description adds value by explaining the stage/apply workflow, providing concrete examples for the criteria parameter, and clarifying file path resolution. This meaningfully supplements the schema.

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

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

The description clearly states the tool detects and permanently redacts sensitive content using the Nutrient AI Redaction API. It specifies the action (detect and redact) and the resource (sensitive content), and lists types of content it handles. It is distinct from sibling tools like document_processor or document_signer.

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

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

The description explains the default behavior (detect and apply) and provides explicit workflow for staging and applying redactions using the stage and apply flags. It mentions mutual exclusivity. While it does not directly compare to siblings, the tool's unique purpose is clear enough. Could be improved by stating when not to use it, but overall good 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by explicitly stating it does not upload any document content, which is not evident from annotations alone. The return values are also described.

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 three sentences, each conveying essential information without redundancy: purpose, safety note, and return structure. 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?

Given no output schema, the description lists the returned fields (subscription type, total/used/remaining credits), which is sufficient for an agent to understand the output. No further context needed.

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?

There are no parameters, and schema description coverage is 100%. The description implicitly confirms no input is needed, so no additional parameter semantics are required.

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

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

The description clearly states it checks credit balance and usage, specifying the resource ('Nutrient DWS API credit balance') and the action ('check'). It is distinct from sibling tools which handle document processing, signing, and file browsing.

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

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

The description provides clear context that this is a read-only account lookup and does not upload content. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, though siblings are clearly different.

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 carry destructiveHint=true and idempotentHint=false, so the mutation profile is established. The description adds genuinely useful context beyond annotations: it reads from the local filesystem/sandbox and writes results back locally. It does not, however, disclose nuances like potential overwriting of the outputPath, long-running OCR/processing times, or that applied redactions permanently alter content — though the schema's createRedactions/applyRedactions two-step does hint at the workflow.

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 the core purpose, then organized into tight bullet groups for features and output formats, closing with a valuable sibling-routing note. Every line earns its place and the list format aids scanning. A small redundancy exists — the output format list partially mirrors the schema's output.anyOf variants — but it is useful as a quick capability overview without needing to open the schema.

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

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

Given the tool's enormous complexity (2 required params, nested instructions object, 8 output variants, 7 action types), the description gives an agent a solid entry point: what it does, its main capabilities, output formats, I/O behavior, and the key exclusion. The schema and its rich descriptions carry the operational detail, which is appropriate. The only notable omission is guidance on how this tool's redaction capabilities relate to the ai_redactor sibling.

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

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

Schema description coverage is 100%, so the baseline is 3. The schema already exhaustively documents instructions, parts, output variants, and actions with detailed descriptions. The description adds only marginal parameter-level value — it restates the high-level feature set and the local/sandbox path resolution, but does not meaningfully augment the schema's parameter documentation.

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 phrase — 'Process, convert, and transform documents using the Nutrient API' — and supports it with a concrete feature list (XFDF import, flatten, OCR, rotation, watermarking, redaction) and output format list (PDF, PDF/A, images, Office, HTML, Markdown). It also explicitly differentiates itself from the parse_document sibling by name and by what that alternative does better (typed JSON/Markdown with bounding boxes and confidence scores).

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

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

The description gives one explicit routing rule: for structured data extraction, 'use the dedicated parse_document tool instead.' It also clarifies the file I/O context (local file system vs. sandbox). However, it doesn't address other potentially overlapping siblings such as ai_redactor (which also performs redaction) or extract_fields, so the guidance is clear but not comprehensive across the full sibling set.

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 indicate destructiveHint=true, so the tool modifies files. The description confirms it writes signed output back locally, which aligns. It adds significant behavioral detail: signature types, appearance customization, positioning options, and reading/writing behavior. This goes beyond the basic annotation hints to inform the agent about the tool's capabilities and behavior.

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

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

The description is well-structured with clear sections, bullet points, and no redundant information. Every sentence provides useful context. It is appropriately sized for the complexity of the tool, front-loading the main purpose and then detailing options efficiently.

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

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

Given the complexity (5 parameters, nested objects, no output schema), the description covers the main aspects: input/output paths, signature types, appearance, positioning. It does not explain the return value or error handling, but since the tool writes a file, the agent can infer output is the signed PDF. The description could mention that the output is a new signed file and whether it overwrites existing files, but it still provides substantial contextual completeness.

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

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

The input schema has 100% description coverage, so each parameter is well-documented in the schema. The tool description adds value by grouping options into categories (signature types, appearance, positioning) and summarizing at a high level, but it does not add significant detail beyond what the schema already provides. Thus a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Digitally sign PDF files using the Nutrient Sign API.' It specifies the type of files (PDF), the API used, and the input/output locations (local file system or sandbox). The sibling tools are different (e.g., ai_redactor for redaction, document_processor for general processing), so this tool is well-distinguished.

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

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

The description explains what the tool does and lists signature types and options, but it does not provide explicit guidance on when to use this tool versus alternatives. For example, it does not mention when to prefer CMS over CAdES or when to use this instead of document_processor. The context of use is implied by the detailed options, but no direct comparison with siblings is given.

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

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

The description adds meaningful behavioral context beyond the annotations: input can come from local files, sandbox paths, or URLs; output.data is always inline; citations and page geometry are retained only when outputPath is set; and cost/billing behavior is explained. It does not explicitly reconcile the destructiveHint:true annotation with specific destructive side effects, but it does not contradict the annotation either, and the annotations keep the disclosure burden lower.

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 dense but every sentence earns its place: core purpose, sibling differentiation, input-source constraint, mode/cost guidance, and output-storage behavior. The most decision-relevant information is front-loaded, and the detail is proportional to the tool's complexity.

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

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

For a 12-parameter tool with nested schema and no output schema, the description covers the essential invocation knowledge: how to choose it, what input it needs, what output it returns, how citations are retained, and the billing model. The remaining details are already present in the 100%-covered parameter schema, so the description is complete enough for an agent to call the tool correctly.

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

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

The input schema already has 100% description coverage, so the baseline is 3. The description still adds value beyond the schema by giving an illustrative extraction shape ({ invoiceNumber, total, lineItems: [...] }), clarifying the exactly-one input rule, and explaining mode-specific cost and output-persistence semantics that are not fully obvious from schema text alone.

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: 'Pull specific named fields out of a document into a JSON shape you define.' It clearly differentiates from parse_document by stating that extract_fields takes a JSON schema and returns only matching values with citations, so an agent can immediately tell what this tool does.

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

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

The description explicitly contrasts with parse_document: 'Unlike parse_document, which parses a whole document into elements or Markdown, extract_fields takes a JSON schema...' It also tells the agent to provide exactly one of filePath or url and explains that there is no text mode. This is clear when-to-use and when-not-to-use 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?

Annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false) are consistent with the description's disclosed writes to outputPath and credit consumption; no contradiction. The description adds high-value context beyond annotations: exact credit costs per mode, the privacy caveat that extracted content 'may be logged by the host,' and the large-output behavior where spatial lists are kept out of the conversation.

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

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

Dense but deliberately structured with bullet lists for output formats and processing modes, making the cost table and format trade-offs scannable. Every sentence carries decision-relevant information — costs, privacy, output destinations, alternatives — and the slight redundancy with schema credit figures is justified because it consolidates the choice into one 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 14-parameter tool with no output schema and zero required parameters, the description covers all invocation-critical aspects: input source constraint, output format destinations, mode costs, privacy/logging implications, and alternative routing to extract_fields. Nothing an agent needs to select a mode, choose a format, or avoid logging sensitive content 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 100%, so the baseline is 3. The description earns extra credit by explaining what each format actually yields (typed elements with bounding boxes/confidence/reading order vs whole-document Markdown) and by clarifying destination behavior — spatial goes to outputPath, markdown is inline or filed. The cost relationships across formats and modes add meaning the schema's enum descriptions only partially convey.

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 opening line states a specific verb+resource: 'Extract structured data from a document using the Nutrient DWS Data Extraction API.' The body further clarifies what 'structured data' means by enumerating spatial vs markdown outputs. It also distinguishes itself from siblings by naming extract_fields as the alternative for sensitive documents, separating parsing from signer/redactor/processor 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?

Contains explicit decision rules: 'provide exactly one of filePath or url,' 'ask for both up front instead of extracting twice,' and mode selection framed by per-page cost/quality trade-offs. The final note gives an explicit when-not: 'For sensitive documents, prefer spatial output to a file plus targeted extract_fields calls,' and markdown is tied to RAG/search indexing use cases.

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

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

The description adds value beyond annotations by specifying it's a local filesystem operation and does not upload. Since annotations already cover readOnlyHint and destructiveHint, the description provides additional context.

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 concise sentences that front-load the purpose and are free of unnecessary detail.

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 zero parameters, no output schema, and low complexity, the description is fully adequate for an agent to understand when and how to use the 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?

With no parameters, the schema coverage is 100%. The description doesn't need to add parameter info, and the baseline is 4.

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

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

The description clearly states the verb 'browse' and resource 'files in sandbox directory', and distinguishes from siblings by noting it's a read-only local filesystem operation that does not upload documents.

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

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

The description provides clear context that this tool is for browsing sandbox files without uploading, helping the agent understand when to use it versus potential upload-oriented siblings like document_processor.

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