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

With no annotations supplied, the description carries the full behavioral burden and provides little: 'Score' implies a read-only analysis, but that is never stated, nor is what happens with unsupported or corrupt files, whether extraction is lossy, or whether runs/backend cause multiple passes or external calls. The only behavioral fact conveyed is the set of accepted file formats.

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

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

A single sentence with no filler that front-loads the verb, the supported formats, and the equivalence reference. Nothing could be cut without losing information.

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

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

For a three-parameter tool with no annotations and no output schema, the description is thin: two parameters are unexplained and the return value is only gesturally covered by deferring to humanizer_assess_text. An agent could call it, but not confidently configure runs or backend.

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

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

Schema description coverage is 0%, so the description must compensate, and it does not. 'path' is self-evident from its name, but 'runs' and 'backend' — which look like they control repeated scoring passes and an underlying provider — are given no meaning at all in either the schema or the description.

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

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

The description gives a specific verb ('Score') and resource ('a PDF, DOCX, Markdown or text file'), and anchors the semantics by equating it to the sibling humanizer_assess_text. It implicitly separates itself from humanizer_humanize_file (transform) and humanizer_assess_text (raw text), though it never states those contrasts 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 phrase 'the same way as humanizer_assess_text' implies the selection rule (use this when the input is a file rather than a string), but the agent must infer it. There is no explicit when-not guidance, no mention of unsupported formats, and nothing about when to reach for humanizer_assess_pair or humanizer_extract_document instead.

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 disclosure burden. It usefully reveals the blinding mechanism ('the assessor is not told which version is the rewrite') and that the faithfulness check enumerates invented, lost, or changed details — real behavioral value. It omits scoring scale/range, determinism, latency/cost, and whether results are persisted.

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 outcome (blind scores + faithfulness check), followed by placement guidance and two clarifying facts. Every sentence adds information; only mild compactness ('blind before and after scores') slightly obscures the mapping to original/rewrite.

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

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

No output schema exists, and the description only loosely sketches the return shape (scores plus a list of invented/lost/changed details) without indicating score range or structure. For a stateless three-parameter evaluation tool this is workable but leaves the response format and the undocumented backend param unresolved.

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 define all three parameters. It clarifies the roles of original and rewritten (the latter being the caller's own rewrite), but the 'backend' parameter is given no meaning at all, and no format or size expectations are stated for the text inputs.

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

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

States a specific action: blind before/after scoring of an original vs. a user-supplied rewrite, plus a faithfulness check. This clearly separates it from the generation tools (humanize_text) and from single-text assessment, though it never names the closest siblings (assess_text, compare) 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?

'Use this after rewriting text yourself' gives a clear triggering condition — the rewrite must already exist and be produced by the caller, not the server. It stops short of saying when to prefer assess_text or compare instead, so alternate routing is left implicit.

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 reasonably well: it discloses the model backend dependency, the relative slowness versus lint_text, the exact return payload (six dimension scores, quoted issues, pattern-checker score), and that runs averages repeats to reduce noise. It omits auth/credential needs implied by the claude-cli and anthropic backends, and any failure or cost 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 purpose and output scale are front-loaded in the first sentence, followed by return shape, then per-argument notes - a sensible order with no filler. The 'Args:' block is slightly list-like but each line adds information the schema lacks.

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

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

For a three-parameter tool with no annotations and no output schema, the description covers purpose, scoring direction, latency tradeoff, return payload, and all three parameters. Missing only edge behavior such as what happens with empty or very long text and how backend credentials are supplied.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: text is the input to assess, backend enumerates the valid choices (auto, claude-cli, anthropic, mock), and runs is explained as repeat-and-average noise reduction rather than just a number. It does not state per-parameter defaults or how auto backend selection resolves, which are the remaining gaps.

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

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

The description gives a specific verb and resource - scoring how AI-written a text reads - plus the output scale (0-100, higher = more AI-like) and the mechanism (blind rubric). It also positions itself against the sibling humanizer_lint_text, so an agent can tell the two apart 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?

It establishes context by noting the model backend makes it slower than lint_text, which implicitly routes latency-sensitive or cheap checks to lint_text. It stops short of an explicit when-to-use / when-not-to-use statement or a recommendation for when the deeper assessment is worth the cost.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the comparison dimensions the tool checks, which is real behavioral context beyond the schema. However it never states that the call is non-mutating/read-only, nor whether it is idempotent or costs anything, which matters for a tool sitting between a rewrite and a save step.

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 core action front-loaded and the output list compactly enumerated, followed by one short imperative sentence for sequencing. No filler, no restatement of the tool name.

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?

Absent an output schema, the description must explain returns, and it does at the level of categories (scores, remaining tells, preservation checks) but not structure or field names. For a two-parameter read-style comparison this is adequate to call correctly, but thin on what the calling agent should expect back.

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. The pair 'original' and 'rewrite' are named in prose ('Compare an original and a rewrite'), which clarifies role ordering, but the description adds no constraint details such as whether inputs are raw text, size limits, or what happens on identical inputs. Minimal viable given two self-describing required string params.

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 (compare) and its two inputs (original, rewrite), then enumerates the concrete outputs: before/after AI-tell score, remaining tells, and survival of numbers, links, emails and quotations. That is far more specific than a tautology. It stops short of differentiating itself from the similarly named sibling humanizer_assess_pair, so an agent must guess which of the two to reach for.

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 sequencing guidance: 'Call this after rewriting, before saving.' That establishes a clear position in the workflow relative to humanizer_humanize_text/humanizer_save_document. It offers no negative guidance (when not to call it) and no routing against humanizer_assess_pair or humanizer_lint_text, so the when-to-use map is incomplete.

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

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

No annotations exist, so the description carries the full burden. It does disclose the read-only nature implicitly and states the output is Markdown, but it omits what happens when max_chars is exceeded (truncation marker? silent cut?), how unsupported or missing files behave, and whether extraction is lossy for tables/images.

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

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

One front-loaded sentence stating purpose and output, followed by a compact args list — no filler. The Args block is slightly redundant with the schema but remains efficient.

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 two-parameter read tool with no output schema this covers the essentials (what is read, what is emitted, a size cap), but it is thin on edge cases — unsupported format handling, truncation signalling, and relative-vs-absolute path failure are all unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does define both params: path as an absolute path on this machine (a useful constraint) and max_chars as a cap on returned text. It still leaves the default value (200000) and the truncation behavior unexplained, which is the most consequential part of max_chars.

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

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

The description names a concrete verb and resource ('Read a PDF, DOCX, Markdown or text file and return its text as Markdown') and enumerates the supported input formats plus the output format. It does not, however, distinguish itself from file-touching siblings such as humanizer_humanize_file or humanizer_assess_file, so an agent must infer that this one only extracts text without processing.

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, and no mention of the sibling tools that also take a file path. Usage is only implied by the verb 'extract', so an agent choosing among humanize_file, assess_file, and this tool gets no routing help.

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 supplied, the description carries the full disclosure burden and does not meet it. It never says whether the removal is permanent or reversible, whether it errors on an unknown phrase, or how it affects future humanization or the voice profile. For a state-mutating removal tool this is a significant 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?

A single short sentence with the action verb front-loaded and no filler. It is appropriately sized, though its brevity comes at the cost of the behavioral detail noted elsewhere.

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 string), but with no annotations and no output schema the description should say what success and failure look like and whether the phrase must already exist. Those essentials are absent, leaving the agent to guess at side effects.

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 is one parameter with 0% schema description coverage, so the schema adds nothing beyond type string. The description partially compensates by indicating the value is a previously learned phrase rather than arbitrary text, but it does not specify exact-match requirements, case sensitivity, or source format.

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 ('Remove') with a specific resource ('a phrase that was learned from the author's edits'), which also implicitly distinguishes it from the sibling humanizer_learn_from_edit. It stops short of naming that counterpart explicitly, so an agent must infer the relationship.

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 guidance, no mention of checking humanizer_get_rules or humanizer_status first to see which phrases exist, and no stated behavior when the phrase was never learned. Usage is only inferable from the phrase 'learned from the author's edits'.

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 disclosure burden. It does usefully disclose the composition of the result and the precedence rule ("Custom rules outrank the defaults"), which is behavior an agent could not infer elsewhere. However, it says nothing about permissions, freshness/caching, or whether custom rules always exist.

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 short sentences, front-loaded with what is returned, then the action guidance and precedence rule. Nothing is padded and each sentence carries distinct information.

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

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

For a simple optional-parameter read tool with no output schema, the description covers content, precedence, and when to call it. The only real gap is the unexplained include_custom flag.

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 the single parameter include_custom, and the description never mentions it. An agent must guess that include_custom toggles the "user's own SOP files" portion, rather than being told directly.

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 ("Return the editing rules") and enumerates the three sources: defaults, installed humanizer skill, and user SOP files. It is clear what the tool retrieves, though it never names a sibling or explains how it differs from humanizer_status or humanizer_voice_profile.

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?

"Read these before rewriting text yourself" gives an explicit invocation condition tied to the humanize workflow. There are no stated when-not conditions or named alternatives, so it stops short of full routing guidance.

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

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

With no annotations supplied, the description carries the full load and does reasonably well: it discloses that the original file is never changed, that output defaults to <name>.humanised.<ext>, that PDF sources are converted to .docx, and that overwrite is required to replace an existing file. It also flags the slower options (assess, semantic). It stops short of describing what happens on failure, whether backend auth is needed, or how long 'deep' level takes.

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 behavioral rules are front-loaded in the first two sentences, followed by a scannable arg list, which is the right structure for a 13-parameter tool. There is minor redundancy, since output_format repeats the PDF-becomes-docx default already stated above, but nothing is padded.

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

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

For a 13-parameter mutation tool with no annotations and no output schema, the description covers the essentials an agent needs: file-safety guarantee, default output naming, format coercion, overwrite behavior, and cost flags. The main remaining gap is the return value — the agent is never told the generated path is reported back, despite there being no output schema to supply it.

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 does by glossing all 13 parameters and supplying the accepted values that the schema lacks as enums (level: light/standard/deep, backend: auto/claude-cli/anthropic/mock, output_format: docx/pdf/md/txt). The glosses are uneven — 'level' values are listed without explaining what depth actually changes, and local_model is not tied to the ollama/openai-compatible backends it belongs to — but the parameter documentation clearly exceeds the bare 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 (rewrite a PDF/DOCX/Markdown/text file) plus the scope constraint that it operates on server files and writes the result alongside the source. That is enough to distinguish it from humanizer_humanize_text, though it never names the sibling explicitly, so the differentiation is inferred rather than stated.

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 by the description of format handling and defaults, so an agent can infer this is the file-based variant of the humanize operation. However, there is no explicit guidance on when to prefer this over humanizer_humanize_text or humanizer_extract_document, and no declared prerequisites such as whether the path must exist or be readable by the server.

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

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

With no annotations, the description carries the full burden, and it does disclose that rewriting happens server-side via a model backend and that some flags are 'slower'. It does not say whether the original text is preserved, whether anything is persisted, what model costs or latency to expect, or what the response contains, leaving meaningful behavioral gaps for a mutating-in-spirit pipeline.

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 purpose sentence followed by one line per argument is efficient and scannable, with no filler prose. The arg block is long but justified because the schema documents nothing 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?

For a nine-parameter tool with no annotations and no output schema, the definition covers inputs but not what comes back: the rewritten text, lint results, and fact-check report are described only as actions, not as returned structure. It also omits whether output is saved versus merely returned, a real ambiguity given the humanizer_save_document 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 0%, so the arg list is the only source of parameter meaning, and it supplies value sets (level: light/standard/deep; backend: auto/claude-cli/anthropic/mock) plus effect hints like 'slower' and default 'auto'. It is undercut by an internal inconsistency: local_model says it applies when backend is 'ollama or openai-compatible', values absent from the backend list, which could cause a failed call.

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 sentence names a specific verb and resource (rewrite text) and discloses the pipeline steps that follow (lint, fact-check), which distinguishes it from pure-assessment siblings. It stops short of explicitly contrasting itself with humanizer_humanize_file or humanizer_assess_text, so the sibling boundary must still be inferred.

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: the arg notes hint that 'assess' or 'semantic' should be turned on for extra scrutiny and that 'voice' relates to humanizer_voice_profile, which is a useful pointer to a sibling. There is no explicit statement of when to prefer this tool over humanizer_humanize_file, humanizer_lint_text, or humanizer_assess_text, 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?

With no annotations the description carries the full burden, and it does real work: it discloses the return contents (changed sentences, removed phrases, general rules) and, critically, that save=true persists effects into the pattern checker and rewrite prompt 'from then on'. That is exactly the kind of durable side effect an agent needs warned about. It stops short of clarifying the scope of persistence (per-user vs global) or what the backend parameter controls.

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

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

Three short sentences, front-loaded with purpose and followed by returns and then the side effect. Every sentence earns its place and nothing is padded.

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

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

For a four-parameter tool with no annotations and no output schema, the description covers purpose, return contents, and the save side effect well. It is incomplete on the backend parameter and on where saved rules and phrases are stored, which matters for a tool with persistent effects.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for three of four parameters: ai_text is the AI draft, edited_text is the hand-fixed version, and save triggers persistent rule/phrase registration. The backend parameter is never mentioned in either schema or description, leaving a genuine hole.

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 - learn the author's taste - and defines the exact inputs that produce it: an AI draft plus the hand-fixed version. That pair-of-texts framing naturally separates it from single-text siblings like humanizer_lint_text, though no sibling is named 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?

Usage is implied by the input shape: call it when you have both an AI draft and a human-corrected version. There is no explicit when-not guidance and no mention of the closely related humanizer_compare or humanizer_assess_pair, which an agent could easily confuse with this tool.

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 disclosure burden and mostly succeeds: it explains the scoring direction (0-100, higher = more AI-like), the grouping of results, and an important behavioral quirk (quotations are skipped except chatbot artefacts). It does not state whether the check is read-only/side-effect free or how large inputs are handled, 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?

Two tightly packed sentences with no filler; the core action is front-loaded, followed by the return shape and the exception rule in one clause. Every sentence earns its place.

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

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

With no output schema, the description usefully enumerates the return payload (score, category counts, per-finding line/text/message/fix), so an agent knows what to expect. It falls just short because the max_findings parameter's role is unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate. 'text' is self-evident and the mention of findings implicitly relates to output, but max_findings (default 100) is never explained — an agent cannot tell from the definition that it caps the number of findings returned or what happens when exceeded.

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

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

States a specific verb and resource ('Check text for AI-writing tells') and adds a distinguishing trait ('without using a model') that separates it from model-based siblings like humanizer_assess_text. It stops short of naming that sibling directly, so the differentiation is implicit rather than explicit.

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 phrase 'without using a model' implies a deterministic, rule-based pass, which hints at when to prefer this over model-backed assessment. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative among the siblings (humanizer_assess_text, humanizer_humanize_text, humanizer_compare).

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 supplied, the description carries the full behavioral burden but does well: it discloses that a same-structure DOCX source is used purely to inherit styles, that overwrite replaces an existing output, and — critically for safety — that the source file is never overwritten. It omits error/failure behavior and what the tool returns, which are the main remaining gaps for a write operation.

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 one-line purpose followed by a compact per-argument block; every line adds information (format constraints, style inheritance, overwrite safety) rather than restating the schema. No padding or 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?

There is no output schema, so the description would ideally state what is returned (e.g., the written path or a confirmation), and it says nothing about directory-creation or failure modes. Otherwise it is complete enough for an agent to call the tool correctly, with format, path, style, and overwrite semantics all covered.

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%, yet the description documents all four parameters: text including its Markdown conventions (# headings, blank line between paragraphs), output_path as absolute with a required extension, source_path as optional with the DOCX style-inheritance condition, and overwrite as replacement of an existing output. This fully compensates for the schema's silence.

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 — 'Write rewritten Markdown text to a .docx, .pdf, .md or .txt file' — and enumerates the supported formats, so an agent immediately knows the operation. It does not, however, distinguish itself from sibling write paths such as humanizer_humanize_file, leaving the boundary implicit.

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: the phrase 'rewritten Markdown text' signals this is a final persistence step after rewriting, and the source_path note hints at a preserve-formatting workflow. There is no explicit statement of when to prefer this over humanizer_humanize_file or humanizer_extract_document, and no stated 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?

With no annotations at all, the description carries the full burden. It does disclose the information returned (backends, rule sources, file types), which implies a read-only, side-effect-free introspection call, but it never explicitly states that it is read-only, whether it is cheap, or whether it touches disk state.

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 compact sentence that front-loads the verb and lists the three payload categories. Every clause carries information; nothing is restated from the tool name.

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 annotations, and no output schema, the description does the important work of enumerating what comes back, which substitutes for the missing return-value documentation. The only gap is that it does not explicitly frame the tool as a read-only diagnostics call.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing the description could add about arguments. It correctly does not invent 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 gives a specific verb ('Show') and enumerates exactly what resource is reported: available rewrite backends, loaded rule sources, and supported file types. This is clearly a diagnostic/capability-introspection tool, which distinguishes it at a glance from action siblings like humanizer_humanize_text or humanizer_lint_text.

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: a 'status' tool is understood to be a preflight/discovery call, but the description never says when to call it, whether it should precede other humanizer tools, or what alternatives exist. No exclusions or conditions are stated.

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

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

With no annotations, the description carries the full burden and does a fair job: it discloses the inputs consumed (samples in a fixed voice folder), the 150-word minimum, and that a model-written description is produced (implying an LLM call with latency/cost). It does not say whether anything is written to disk or cached, whether the call is read-only, or how failures surface.

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

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

Three short sentences, front-loaded with purpose followed by the return payload and then the constraint. No filler, though the return-value list is a flat enumeration that 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?

The description compensates for the absent output schema by sketching the return payload, which is the right move. However, for a two-parameter tool with zero annotation and zero schema coverage, leaving 'backend' and 'refresh' undefined is a real completeness 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% and neither parameter is mentioned in the description. 'Backend' is completely unexplained — an agent cannot tell what values are valid or what it selects. 'Refresh' is only obliquely inferable from the caching behaviour the tool implies, not stated.

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: 'Measure the author's writing habits from the samples in the voice folder.' This is clearly distinct from the assess/lint/humanize siblings, though it never names or contrasts with any of them, leaving the agent to infer the division of labor.

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 one hard precondition — 'At least 150 words of samples are needed' — is stated, which is genuinely useful. But there is no guidance on when to choose this over humanizer_assess_text or humanizer_learn_from_edit, and no note on what happens below the threshold (error vs empty profile).

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