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

No annotations are provided, so the description carries the full burden of behavioral disclosure for a mutating tool. It does not say what preview mode returns versus what creation does, what permissions are required, whether the field is immediately active on existing documents, or how to roll it back — 'standard Frappe REST API' is the only behavioral hint.

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 single sentence is front-loaded and free of padding, so it satisfies the structural bar. It is, however, under-specified rather than concise — the brevity comes at the cost of the information the tool needs.

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

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

An output schema exists, so return values need not be explained, and that is the only thing the description gets for free. For a 5-parameter write tool with a nested object and zero annotations, the description leaves critical gaps around preview semantics, required permissions, and field-object structure.

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?

Five parameters with 0% schema description coverage, including a nested free-form 'field' object, and the description explains none of them. It does not clarify what 'app' and 'module' scope means, what keys the 'field' object expects, or what 'confirm' toggles — all of which an agent must guess.

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 pairs a specific verb (create) with a specific resource (Custom Field), and mentions a preview mode, so the basic action is identifiable. However, it never distinguishes this tool from plausible alternatives in the sibling list such as create_doctype or set_field_property, and the 'Preview or create' phrasing leaves the actual mode of operation ambiguous.

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?

There is no guidance on when to use this versus set_field_property, create_doctype, or export_customizations, which all touch schema customization. Nothing explains the role of the 'confirm' parameter in choosing between preview and creation, so the agent must infer the workflow.

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 it does disclose meaningful traits: standard DocTypes generate JSON, Python, JavaScript, and test files on disk, while custom ones only touch site metadata. It omits what happens if the DocType already exists, whether writes are reversible, and what permissions are required for the write path.

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?

Four short sentences, front-loaded with the operation and followed by the two mode-specific constraints. No filler, though a sentence on `confirm` would have been worth more than the softer wording about 'supported DocType-level settings'.

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

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

An output schema exists so return values need no explanation, and the mode distinction is covered. But for a 12-parameter creation tool with no annotations, the silence on `confirm`, `is_custom`, and `permissions` leaves the agent without enough to invoke it confidently.

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% across 12 parameters, and the description only explains `fields` and `properties`. Critical flags like `confirm` (the preview/create gate), `is_custom` (which mode is selected), `is_submittable`, `is_child_table`, and `permissions` are left with bare titles, so the agent must guess.

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+resource ('Preview or create a standard or site-custom DocType') and immediately differentiates two modes. It is distinguishable from the sibling create_document (records, not schema), though the word 'Preview' is never tied to an argument.

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 explains prerequisites for each mode — standard types need an app/module checkout and Developer Mode, site-custom types live in site metadata — which implies when each is viable. But it never says how to choose between them for a given task, nor how to trigger preview versus actual creation, and it offers no exclusion against create_document or create_custom_field.

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 of behavioral disclosure. It implies a possible mutation but does not state defaults, side effects, permission requirements, duplicate handling, or what preview returns. 'Native REST resource API' adds context but little behavioral transparency.

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 no filler. Its compactness comes at the cost of clarity, which keeps it from a 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?

For a tool with three parameters, a nested values object, no annotations, and 0% schema documentation, one sentence is insufficient. Doctype selection, values shape, and confirm semantics are all unexplained. The presence of an output schema reduces the need to describe return values, but the call semantics remain incomplete.

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 three parameters. The description never explains doctype, values, or confirm, nor does it clarify the shape of the nested values object. 'Preview or create' faintly gestures at confirm but does not document it.

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

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

The description states a specific verb ('create') and resource ('document'), making the core purpose clear. However, 'Preview or create' introduces ambiguity about whether the default behavior is a write, and no sibling tool is named to distinguish it from update_document or get_document.

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?

There is no explicit when-to-use or when-not-to-use guidance. The word 'preview' hints at a non-committal mode but is never connected to the confirm parameter, and there is no advice to call get_doctype_schema first to discover required fields.

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 confirmation requires a modified token from a preview call, which is important for a destructive operation, but it omits irreversibility, permission requirements, and what the preview versus delete responses contain.

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 no filler. It is concise, though its terseness leaves important structure and parameter guidance unstated.

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 destructive, four-parameter tool with zero schema description coverage and no annotations, one sentence is insufficient. The output schema may cover return values, but the description still fails to explain doctype/name semantics, preview output, or deletion consequences.

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 explain all four parameters. It indirectly explains confirm and expected_modified via the confirmation-token workflow, but says nothing about doctype, name, or how expected_modified relates to the record's version.

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 two verbs (preview or delete) and the resource generically as 'record,' while the tool is named delete_document. It communicates the dual-mode nature but blurs what exactly is being deleted and does not differentiate the preview behavior from siblings like get_document or update_document.

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 implies a two-step workflow: preview first, then confirm using the preview's modified token. However, it never explicitly says when to use preview versus delete, how to trigger each mode, or when to prefer alternatives such as get_document for inspection.

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. 'With rollback' implies a safety mechanism but doesn't explain what is written, whether files are created or mutated, what confirm guards, or whether preview is non-destructive; these are significant gaps for a write-oriented 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?

A single front-loaded sentence with no filler; efficient. It could earn a 5 only if it spent those words on mode selection or parameter meaning rather than the vague 'with rollback' clause.

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

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

An output schema exists, so return values needn't be explained, but with 5 undocumented parameters, no annotations, and an unexplained preview/export duality, the description is far too thin 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 0%, so the description must compensate, but it only loosely maps 'app'. It says nothing about module, doctypes, confirm, or expected_preview — the latter clearly ties into the preview workflow yet is entirely 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?

The description names a specific verb (export) and resource (DocType JSON and customization fixtures) with a target (an app), which is clear enough to distinguish it from CRUD siblings like get_doctype_schema. However, it doesn't differentiate the 'preview' mode from an actual export or acknowledge the separate rollback_export sibling, leaving some ambiguity about its exact scope.

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 hints at two modes ('Preview or export') but never states when to choose one over the other, nor when to use the sibling rollback_export instead of the built-in rollback. No prerequisites or conditions are given for confirm/expected_preview, leaving the agent to infer usage entirely.

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 full burden; it does disclose that this is a read operation and that visibility is through Frappe's API (implying permission-based results). However, it omits auth requirements, rate limits, and explicit read-only confirmation beyond the verb 'Read'.

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 with zero wasted words. It efficiently states the core action and scope without 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?

The tool is simple (one required parameter) and has an output schema that covers return values. Still, the description leaves the parameter undocumented and provides no usage context, which prevents it from being fully self-contained despite the low 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 0% and the description never mentions the required 'doctype' parameter directly. The agent can infer that the parameter expects a DocType name, but no details on format, case sensitivity, or naming conventions are added beyond what the parameter name implies.

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 has a specific verb ('Read') and resource ('DocType schema and field metadata'), clearly distinguishing it from document-level siblings like get_document. However, it does not explicitly differentiate itself from list_doctypes, which also deals with doctypes, leaving a minor inference gap.

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 no explicit when-to-use guidance, no alternatives (e.g., 'use this before create_document to learn fields'), and no prerequisites or exclusions. It only states the purpose, leaving the agent to infer usage 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 must carry the full behavioral burden. 'Read' implies non-mutation and 'bounding' implies child-row limiting, but it does not disclose permissions, not-found/error behavior, whether child rows are silently truncated, or how the limit interacts with the returned output.

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 a single front-loaded sentence with no wasted wording. It states the action and two important behaviors immediately.

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

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

An output schema exists, so return-value details need not be repeated. Still, the definition is thin for a 4-parameter read tool with no annotations and no schema descriptions, leaving gaps around required parameters, permissions, error behavior, and sibling selection.

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 meaning for fields ('selecting fields') and child_row_limit ('bounding any returned child-table rows'), but leaves doctype and name unexplained and does not clarify formats or the default child-row limit.

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

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

The description states a specific verb and resource: 'Read one document.' The phrase 'one document' distinguishes it from sibling listing tools such as list_documents, and it also names the field-selection and child-row-bounding behavior.

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: this is the tool for fetching a single document by doctype and name. However, it does not explicitly say when to use it instead of list_documents, get_doctype_schema, or other siblings, and it gives no exclusions or prerequisites.

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 and it does little beyond implying a read-only list. It doesn't say what a result entry contains, whether results are truncated at the default limit of 500, or that child tables are included by default — behaviors an agent needs to interpret output.

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 with the resource first and the filter second; no filler. It is efficiently written, though efficiency comes partly from omitting content the reader needs.

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

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

An output schema exists, so return-value detail is not required, but with zero annotation coverage and 0% parameter descriptions the definition leaves limit/child-table semantics and output truncation entirely unexplained. For a list tool with a 500-item default cap, that is a meaningful 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 description coverage is 0%, so the description should compensate, yet it only gestures at app and module while saying nothing about limit or include_child_tables. Two of four parameters are effectively undocumented anywhere, and the two it mentions get no added meaning beyond their names.

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 ('List DocTypes on the site') plus the optional filter axis, which is enough to separate it from siblings like get_document or list_documents. It doesn't explicitly name the nearest sibling (get_doctype_schema), 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?

'optionally filtered by app/module' describes parameter behavior, not tool selection. There is no statement of when to prefer this over get_doctype_schema (schema lookup) or list_documents (data listing), and no prerequisites or exclusions are 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?

No annotations are provided, so the description carries the full burden. It does disclose one real behavioral trait — results are 'permission-filtered' — but says nothing about default page size (limit=20 in schema), ordering, pagination, or what happens with an invalid doctype. For a query tool with zero annotation coverage, this is thin.

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 tight sentence with the scoping qualifier ('permission-filtered') front-loaded and no filler. It is efficient, though efficiency here partly reflects under-specification rather than disciplined editing.

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

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

An output schema exists, so return-shape explanation is not required, but the description still leaves the agent without the doctype/filters/limit semantics needed to call a 4-parameter listing tool correctly. Given no annotations and 0% schema coverage, this is well short of adequate.

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% across four parameters, so the description must compensate and largely fails. 'fields' is faintly gestured at by 'records and fields' and 'standard Frappe REST API' hints at Frappe filter syntax, but doctype, limit, and the shape of filters are never explained.

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 verb 'List' and the object 'records and fields' are present, giving a rough sense of a query operation, but the phrasing is abstract and never mentions 'documents' or 'doctype', which is the required parameter and the real subject of the tool. Nothing distinguishes it from siblings such as get_document, list_doctypes, or run_report.

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?

There is no guidance on when to use this versus get_document (single record) or run_report, and no mention of preconditions such as needing a known doctype. The phrase 'standard Frappe REST API' implies a convention but gives no selection criteria.

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, but 'list/discover' plus zero parameters make the read-only nature self-evident. It adds useful domain context that results derive from Module Def records on the target site, though it says nothing about scope across sites or result volume—mitigated by the presence of an output schema.

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 with no wasted text. Minor jargon ('Module Def records') assumes Frappe familiarity but earns its place by tying the tool to its data source.

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 listing tool with an output schema, the description is nearly sufficient: it states the resource and its provenance. The only gap is what 'target site' resolves to, which could matter for an agent operating across sites.

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 is 4. The one semantic detail worth noting—that the target is the 'target site'—is mentioned in the description, though it doesn't explain how that site is determined, since there is no parameter for it.

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 resource ('apps and modules') and grounds it in the underlying data source ('Module Def records'), which distinguishes it from document/doctype siblings like list_doctypes and list_documents. The verb 'discover' is softer than the tool name's 'list', but the intent is 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?

Usage is only implied by the resource: call it when you need to know what apps/modules are installed. There is no explicit when-to-use vs. when-not, and no pointer to alternatives such as list_doctypes, which an agent could easily confuse it with.

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 behavioral burden. It usefully states that later edits are not overwritten, but it does not explain permissions, what confirm changes, whether restore is irreversible, or how expected_preview affects behavior.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise, though its brevity contributes to missing workflow detail rather than being a structural flaw by itself.

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 helps with return values, but this is a five-parameter mutation-capable tool with zero schema description coverage and no annotations. The description gives only the high-level purpose and safety condition, leaving required workflow and parameter context incomplete.

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% and the description does not explain any of the five parameters. Critical fields such as confirm and expected_preview are left especially opaque for a preview/restore workflow.

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

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

The description uses a specific verb and resource: preview or restore files from an export manifest. It clearly distinguishes preview from restore, but it does not explicitly differentiate this tool from nearby export/customization siblings.

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 preview/restore framing implies when the tool is useful and the safety clause hints at using preview before restore. However, it gives no explicit when-not guidance, prerequisites, or named 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 does disclose that the query is 'permission-checked', which is genuinely useful behavioral context about access scoping. However it omits that this is a read-only operation, says nothing about result size, pagination, or what the default limit of 200 implies.

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 with no filler. It is efficient, though its brevity is partly the source of the missing detail rather than a virtue in itself.

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

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

An output schema exists, so return values need not be explained, but for a 3-parameter tool with zero schema coverage and no annotations the description leaves too much open: the filters object format, the meaning of limit, and the failure mode for disabled reports are all 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 description coverage is 0%, so the description must compensate and does not: 'filters' and 'limit' are never mentioned, even though filters is a free-form object whose expected shape is the hardest part of the call. Only 'report_name' is indirectly explained via the 'enabled report' phrasing.

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 ('Run') and resource ('report') and adds the constraint that the report must be 'enabled'. It implicitly distinguishes itself from the document CRUD siblings, though it never names them explicitly.

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

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

The only usage signal is the word 'enabled', which hints at a precondition but gives no guidance on when to choose run_report over list_documents or get_doctype_schema, and no mention of what happens with a disabled or unknown report.

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 must disclose behavioral traits itself. It hints at a preview/save distinction but does not explain what confirm does, whether saving is reversible, what permissions are needed, or what side effects occur in save mode.

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 no wasted text, but it is overly sparse rather than appropriately concise. Its brevity reflects under-specification more than efficient communication.

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?

This is an eight-parameter mutation tool with no annotations and zero schema description coverage, yet the description provides almost no context about required inputs, preview versus save behavior, or risks. An output schema exists, but the missing behavioral and parameter context makes the definition inadequate for safe 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?

The schema has eight parameters with 0% description coverage, and the description does not explain any of them. Terms like app, module, doctype, property, property_type, fieldname, value, and confirm are left entirely ambiguous, especially for a high-complexity mutation 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?

The description names an action ('Preview or save') and a target ('Customize Form value as a Property Setter'), so it is more than a restatement of the tool name. However, the phrasing is jargon-heavy and does not clarify what a Property Setter is or how it differs from sibling tools like create_custom_field or export_customizations.

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 no guidance on when to use this tool versus alternatives, when not to use it, or what prerequisites such as permissions or confirm state apply. An agent is left to infer usage entirely from the name and parameters.

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 but only discloses that preview and mutation are both possible. It does not explain permissions requirements, reversibility, side effects, default behavior, or what confirm changes.

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 single sentence is front-loaded and free of filler, so it is efficiently structured. It is very terse for a complex mutation tool, but conciseness itself is not the issue.

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, nested-object mutation tool with no annotations and no schema descriptions, the description is far too thin. Although an output schema exists, the agent still lacks essential context about confirm semantics, permission shape, and permlevel behavior.

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 undocumented parameters. It mentions DocType, role, and permissions at a high level, but does not explain confirm, permlevel, or the boolean structure of the permissions object.

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 verb pair ('Preview or set') and resource ('DocType role permissions'), making the tool's purpose clear. It does not explicitly distinguish this tool from nearby siblings such as set_field_property or export_customizations, so it falls short of the top score.

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

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

It says 'Preview or set' but gives no guidance on when to preview versus when to apply changes, nor how that choice relates to the confirm parameter. No alternatives or exclusions are mentioned.

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 a non-obvious optimistic-concurrency constraint: confirmation requires the preview's modified token. It does not mention permissions, side effects, reversibility, or what happens if the token is stale or missing.

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 no filler. It clearly separates the core action from the confirmation requirement via a semicolon.

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?

This is a mutation tool with five parameters, nested values, no annotations, and zero schema description coverage. The description provides only one workflow detail, leaving important context like permissions, side effects, parameter meaning for doctype/name/values, and error behavior missing. Output schema exists, so return values need not be explained, but the call context is still incomplete.

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 parameters. It only indirectly explains 'confirm' and 'expected_modified' via 'confirmation' and 'modified token'; it says nothing about 'doctype', 'name', 'values', or the nested object, leaving most 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 states a clear action ('Preview or update') and resource ('record'), so an agent can grasp the core operation. However, it uses the generic term 'record' rather than 'document', and it does not distinguish this tool from siblings like get_document or create_document.

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 a two-step preview-then-confirm workflow by saying confirmation requires the preview's modified token. It does not explain when to use this tool rather than get_document or create_document, nor does it state any exclusions or prerequisites.

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