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

With no annotations, the description carries the full burden and does so well: it discloses the complete return shape, receipt hashing semantics, actor-vs-author separation, optimistic version checking on Replace, and critically 'On any failure nothing is written' (atomicity). This is exactly the mutation/atomicity context an agent needs before committing a write.

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, then return shape, then receipt, then saveMode behaviors. Dense but every sentence carries load given the absent output schema. The long inline return-field list is justified but slightly dense to parse.

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 return values, failure atomicity, and saveMode differences, which is more than enough given there is no output schema and no annotations. The main residual gap is where a DocumentPlan comes from (presumably preview_plan) and its expected format, but nothing needed to invoke correctly is missing.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: all three saveMode values are spelled out with their distinct semantics, newName is tied to NewDocument, and connectionId/documentId are anchored to the apply target. planJson and the DocumentPlan format itself remain only lightly characterized, keeping it out of the top band.

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: 'Apply a DocumentPlan JSON to (connectionId, documentId) and save through the provider.' The action is unambiguous and clearly implies the committing counterpart to preview_plan. It stops short of explicitly differentiating itself from siblings like preview_plan, so it lands just under the top band.

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 rather than stated: the saveMode enumeration tells you the write destinations available, but there is no explicit 'use this when you intend to persist, use preview_plan when you only want to inspect.' No when-not guidance or named alternatives are given, so the agent must infer the 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 and does well: it states the tool writes nothing, discloses the limitation that only free body paragraphs are covered in the first version, and specifies failure behavior (unsupported changes set isComplete false and plan null). It stops short of permission/auth or performance details, but the mutation and failure semantics are 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?

Four tight sentences, front-loaded with the core action and outputs before the caveats. Every sentence adds information (returned fields, coverage scope, failure mode, write semantics); no wasted filler.

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

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

With no output schema, the description usefully describes the return payload (differences, hashes, diagnostics, plan) and the isComplete/plan-null contract. The remaining gap is parameter-level meaning for five required, undocumented inputs, but the overall behavioral picture is complete enough to invoke 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?

All five parameters are required with 0% schema description coverage, so the description must compensate and largely does not. It conveys an original/revised pairing and 'bound to the original snapshot,' and mentions revisionAuthor only obliquely, but never explains the connectionId vs. documentId distinction or the role of each parameter.

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 (read/compare) and resource (two Word documents) and enumerates the outputs: paragraph differences, SHA-256 hashes, coverage diagnostics, and a tracked-change plan. It distinguishes itself as a non-writing producer of a plan, though it never names a sibling tool explicitly (e.g., preview_document_merge) to sharpen the contrast.

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?

Workflow guidance is implied by 'This tool writes nothing; preview and apply the returned plan against the original document,' which situates it before preview_plan/apply_plan. However, it gives no explicit when-to-use vs. when-not criteria or named alternative for comparison/merge scenarios.

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 and largely meets it: it discloses atomicity ('Nothing is written unless every operation validates'), named error conditions ('ambiguous-anchor', 'anchor-not-found'), the zero-based match-index retry mechanism, and the return shape including sourceDocumentId being usable 'even when the edit failed'. Permissions/rate limits are unaddressed but are not central to correct invocation here.

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 critical routing statement and the one-call summary are front-loaded, and the inline JSON examples earn their space by making the target syntax actionable. It is dense and somewhat long with several nested inline structures, but virtually no sentence is padding.

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, but the description compensates by describing the return ('apply_plan shape plus sourceDocumentId'). Atomicity, error codes and retry semantics are all present. The remaining gap is two under-specified required inputs (connectionId, and the exact nature of source), which an agent must guess at.

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 does so thoroughly for planJson (accepted shapes, operation list contents, target object form, mixing paraId/expect anchors) and points to apply_plan for saveMode/newName. However, source is left vague ('a document the user named by source' — name? path? id?) and connectionId is never explained at all.

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 and resource (edit a document the user named by source) and explicitly enumerates what it does in one call: registers, resolves targets, applies operations. It also names the exact siblings it supersedes (register_document + find_in_document + apply_plan), so an agent can discriminate it from them 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?

Explicit routing guidance: 'use this instead of register_document + find_in_document + apply_plan', plus a stated precondition-free path (targets may name text directly 'so no lookup call is needed first'). It also covers what to do on the two failure modes, i.e. when to re-issue with a match index or longer text.

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 add real behavioral detail: the Excel search can span displayed, raw, or both representations, and results are anchored by sheetId plus A1 address. It still omits permission/auth needs, error behavior, and whether the operation is strictly read-only.

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 dense sentences with the core capability front-loaded and no filler. The Excel-specific nuance is appended after the general purpose, which reads well.

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 7-parameter, zero-coverage, annotation-free tool, the description is only partially complete. It helpfully discloses return anchors, but with no output schema there is no explanation of overall match shape, multi-match behavior, or pagination.

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 7 required parameters, so the description must compensate. It usefully clarifies spreadsheetValueView semantics (displayed, raw, or both), but leaves pattern, regex, wholeWord, and caseSensitive to be inferred purely from 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 (Find) and resource (content) plus the supported document types (Word, PowerPoint, Excel), so the agent knows exactly what the tool operates on. It does not, however, distinguish itself from the sibling inspect_document, leaving overlap for the agent to resolve.

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 inspect_document or edit_document, no mention of prerequisites such as an opened/registered document, and no exclusions. Usage is only implied by the name.

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 per-format return shape and hints at chaining ('copy anchors and node paths from this result'), but says nothing about permissions, the meaning of the fidelity levels, or pagination behavior for the paragraph offset/limit pair.

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 sentences, front-loaded with the tool's scope, then branch-specific behavior, then a chaining hint. No filler, though the parameter list in the middle sentence could be tightened.

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, all-required tool with no annotations, no output schema, and zero schema coverage, the description leaves most of the contract unexplained. Return shape is sketched, but pagination, fidelity semantics, and required identifiers are absent, which is insufficient 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 0% across 8 required parameters, so the description must compensate and largely does not. It explains only sheetId, range, and maximumCells; fidelity, paragraphOffset, paragraphLimit, connectionId, and documentId are left entirely opaque.

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 (inspect) and resource (Word/PowerPoint/Excel document), and goes further by spelling out the differing return shape per format. It implies a read-only inspection role that separates it from edit_document and open_document, though it never names those siblings 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 Excel clause gives concrete narrowing guidance (sheetId, range, maximumCells), which is genuine when-to-use advice for that branch. However, there is no guidance on when to prefer this over find_in_document, open_document, or preview_plan, so the overall routing decision is left to inference.

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 does disclose behavior beyond structure: it enumerates the return fields, pins the provider enum values ('filesystem' or 'sharepoint'), and adds the non-obvious directive never to ask the user for a connectionId. Remaining gap is that canCreateDocuments' meaning is left implicit.

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 sentences, front-loaded with the purpose, then the return shape, then the actionable usage rule. No filler and nothing repeated from structured fields.

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 read tool with no annotations and no output schema, the description compensates well by describing the returned fields and their use in the document workflow. Slight gap: canCreateDocuments' semantics and whether the list can be empty are not addressed.

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 input parameters, so baseline is 4. The description goes further by documenting the output fields (connectionId, provider, canCreateDocuments), which is the only place that information exists given there is no output 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?

States a specific verb (List) and resource (connections), plus the scope ('you can address documents under'), which distinguishes it from sibling document tools like open_document and register_document. It even describes the return shape, so an agent knows exactly what this yields.

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 downstream guidance: use the returned connectionId for register_document and the document tools, and never ask the user for it. It doesn't explicitly say 'call this before register_document', but the routing intent is clear enough to act on.

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 so well: it discloses the side effect (registers the document), the connection-specific nature of source, the accepted source formats (filesystem path, SharePoint/OneDrive URL, driveId/itemId), and the returned field set plus inspect payload. It omits permission/auth requirements and any idempotency or collision behavior, which keeps it short of 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?

Front-loaded with the core action and the sibling-routing instruction, then progressively discloses source formats, return fields, and paging. It is dense but every sentence conveys operational information; only the exhaustive enumeration of payload fields borders on excess.

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, no-annotation, no-output-schema composite tool, the description helpfully spells out the return shape and follow-up guidance. However, it leaves the fidelity/sheetId/range/maximumCells parameters unexplained, which is a notable gap given the complete absence of schema descriptions and annotations.

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 only partially does: 'source' and the paragraph paging behavior are explained in useful detail. connectionId, fidelity, sheetId, range, and maximumCells are not described at all, leaving five of eight parameters without any semantics anywhere.

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 ('Open a document the user named by source') and defines the composite behavior ('registers it and returns its inspection in one call'). It explicitly names the sibling tools it replaces, so an agent can distinguish it from register_document and inspect_document 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?

Directly instructs 'use this instead of register_document followed by inspect_document', giving both the alternative and the condition that selects this tool. The follow-up note ('Keep documentId for follow-up calls; paging works as in inspect_document') further routes subsequent calls.

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 burden, and it does so well: it states nothing is saved, that source formatting is preserved within a documented compatibility scope, that each document starts on a new page, and that the result is bound to exact input hashes. It does not discuss auth requirements or size/rate limits, leaving minor gaps.

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 tightly packed sentences, front-loaded with the core action and scope, each carrying distinct information (behavior, input shape, return content, exclusion). No redundancy.

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

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

With no output schema and no annotations, the description supplies the return-value summary (merge plan, hashes, remapping decisions, blocking diagnostics) as well as the input shape and safety profile, making it largely self-sufficient. A little more on preconditions or expected failure modes would round it out.

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 there are no nested-object hints, so the description must explain the single requestJson parameter — which it does by spelling out sources [{connectionId, documentId}] in output order and optional options {title, author}. This meaningfully compensates for the undocumented 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?

States a specific verb and resource ('Preview ordered whole-document Word assembly') and explicitly routes away from the wrong interpretation ('This is assembly, not reconciliation of edited versions'), which distinguishes it from the compare_documents sibling.

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?

'Preview ... without saving' clearly signals the dry-run context before an actual apply, and the closing sentence excludes the reconciliation use case. It stops short of naming compare_documents or apply_plan explicitly as the alternatives, so 4 rather than 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 load and mostly delivers: it discloses the exact return shape, that output fields are null and committed is false (i.e. nothing is written), the drift-detection behavior of the snapshot, and engine behaviors like a shared timestamp when timestampUtc is omitted. It does not mention auth/permission requirements or rate limits, which is the remaining gap.

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

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

The first sentence is well front-loaded and the body is organized under comment-delimited headings, which aids scanning. But the length is extreme for a tool description; much of the operation catalog reads as a DSL reference manual, and trimming examples to the least obvious verbs would preserve the value with far less bulk.

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?

There is no output schema, so the description correctly enumerates the return object itself. For a tool whose real complexity lives in an untyped JSON string, the coverage is strong; the residual gap is the two identity parameters, whose provenance (inspection, connection listing) is never stated.

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 planJson is an opaque string, so the description must carry all semantics — and it does, exhaustively documenting the plan envelope (snapshot/revision/operations) and every operation verb with concrete examples. The only shortfall is connectionId/documentId, which are mentioned as a tuple but never explained (their source, format, or that list_connections provides them).

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?

Opens with a precise verb+resource: dry-run a DocumentPlan against (connectionId, documentId). The word 'dry-run' combined with 'committed is false' immediately distinguishes it from apply_plan, so an agent can route between the two without opening either 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?

Usage is implied rather than stated: the dry-run framing suggests validating before a real apply, and the snapshot guidance says 'Omit it only intentionally', but the description never explicitly says 'call this before apply_plan' or when to skip previewing. It gives rich guidance about how to author the plan, not about when to invoke this tool versus its 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?

Discloses output format, warns not to pass credentials, and explains source format specifics. With no annotations, it provides good behavioral context, though could mention error handling or idempotency.

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?

Appropriately sized with front-loaded action and return info. Includes examples and warning, no unnecessary fluff, though could be slightly more compact.

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, parameter semantics for source, output format, and a safety note. Missing error behavior and connectionId details, but sufficient for a simple registration tool with two parameters.

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%, but description explains 'source' parameter in detail with examples. 'connectionId' is not described beyond being a connection identifier, leaving some ambiguity.

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

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

Clearly states it registers a document and returns a documentId. Explains source formats for different connections, distinguishing it from sibling tools like find_in_document or list_connections.

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?

Implied usage (registering a document) but no explicit when-to-use vs alternatives or prerequisites. Sibling tools are different enough that context is clear, but lacks direct 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 adds key behavioral detail: 'the underlying file is never deleted' and specifies the return format. It does not cover idempotency or error states, but the most critical trait is disclosed.

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, no redundancy, front-loaded with the action and key constraint. Every word adds value.

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 0% param coverage, the description covers the essential purpose, key behavior, and return structure. It lacks error handling or prerequisites, but for a simple removal tool it is largely sufficient.

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 names the required parameters (connectionId, documentId) and indicates their role via 'by (connectionId, documentId)', but adds no additional detail about format or constraints, which is minimal for the context.

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 'Remove' and the resource 'document registration', specifying it only removes the registration without deleting the file. It distinguishes from siblings like register_document by its inverse action.

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 when to use (to remove a registration) but lacks explicit guidance on when not to use it or alternatives. No mention of prerequisites or context compared to siblings like list_connections or inspect_document.

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