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

With no annotations provided, the description carries the full behavioral burden. It discloses the core action (creates a new .docx from Markdown), dual input modes (text or file path), and optional template application. It does not disclose edge behaviors such as what happens when both markdown and markdown_path are supplied, overwrite behavior for existing files, or what the function returns on success.

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 clauses, each carrying a distinct piece of information: core conversion, supported elements, and optional template. The main action is front-loaded in the first sentence with zero filler or repetition.

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 7 parameters (including a deeply nested theme object), no annotations, and no output schema, the description covers the primary behavior and supported features but omits integration-level context: how theme input relates to save_theme, how conflicting inputs are resolved, and what the success/error return looks like. It is minimally viable but has meaningful gaps.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters and the nested theme object. The description adds modest value by confirming which markdown constructs are supported (relevant to the markdown param) and that a template can be applied (relevant to theme/theme_path), but it does not go beyond that.

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+resource pair: converting Markdown text or .md files into a professionally formatted Word (.docx) document, and enumerates supported content types (headings, paragraphs, lists, tables, code blocks, quotes). This clearly distinguishes it from siblings like save_theme and list_themes, which are about theme management rather than document conversion.

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 usage context is implied: use this when you have Markdown content and want a Word output, optionally with a corporate template. However, the description gives no explicit guidance on when to prefer this over create_document, nor does it mention exclusions or prerequisites, leaving the routing decision 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly reveals the main side effect, creating a formatted .docx document, and mentions theme, logo, and header/footer handling. However, it does not describe output path behavior, overwrite semantics, return value, or failure modes, leaving some operational behavior 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?

The description is a single sentence that leads with the action and resource, then lists supported features in a compact, informative sequence. Every phrase adds orientation value, and there is no redundant or filler content.

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

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

Given the tool's complexity, nested block schema, theme object, and lack of an output schema, the one-sentence description provides a useful overview but leaves operational context implicit. It does not clarify expected behavior around output_path, the relationship between theme and theme_path, or what the caller should expect as a result. The rich input schema compensates for part of this gap, but not all of 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 description coverage is 100%, so all seven parameters are already documented in the input schema. The description adds a high-level framing for blocks and themes, but it does not provide parameter-level meaning beyond what the schema already states, matching the baseline for full schema coverage.

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 ('Vytvoří') and resource ('Word (.docx) dokument'), then lists the supported content types such as headings, paragraphs, lists, tables, callouts, and header/footer with logo and theme. This clearly defines the tool's function and distinguishes it from siblings like convert_markdown, save_theme, and list_themes.

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

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

The description implies the tool is for generating .docx files from structured blocks, but it does not explicitly state when to prefer it over convert_markdown or when not to use it. No exclusions, prerequisites, or alternative routing are mentioned, so the agent must infer the boundary from sibling tool names.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It reveals the operation is a read-only listing and specifies the source directory (~/.docx-mcp/themes/). It does not mention edge cases like missing directory, but for a zero-parameter list tool this is adequate.

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 one short, front-loaded sentence containing exactly the needed information: what is listed, the resource type, and the storage location. No wasted words or redundant restating 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?

For a simple zero-parameter list tool with no output schema, the description is complete: it tells the agent the action and the data source. The result is implied to be a list of themes. Nothing essential is missing for a correct 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 has zero parameters, so the empty schema fully covers the parameter space. The description correctly does not invent parameter guidance. A score of 4 reflects the 0-param baseline.

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 action ('Zobrazí seznam' - displays a list) and the resource (saved themes from ~/.docx-mcp/themes/). This distinguishes it from sibling tools like save_theme, which writes rather than reads, and document creation/convertion tools.

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

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

The usage context is clear: this tool should be used when you need to see the list of already saved themes. Since there is no alternative 'list' sibling, explicit exclusion is not critical, though it does not name alternatives or state when not to use it.

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 behavioral transparency. It discloses the default save location (~/.docx-mcp/themes/<name>.json), which is useful. However, it does not clarify whether existing files are overwritten, whether directories are created, or what errors occur, leaving behavioral 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?

The description is a single sentence that leads with the verb and resource, immediately stating the core purpose and default location. It contains no filler and is easy 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?

The tool has a nested `theme` object and an optional `output_path`, but the description ignores `output_path` and does not explain overwrite behavior or return values. The schema covers both parameters, which helps, but without annotations and output schema, a bit more context would be needed for fully confident use.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-related context beyond the schema (only that `name` determines the default path). It does not enrich understanding of `theme` or `output_path`, but the schema already documents them thoroughly.

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 a specific action ('Uloží šablonu') with a resource ('theme') and target format ('JSON soubor'), plus the purpose 'pro opakované použití' (for reuse). This distinguishes it from siblings like create_document, convert_markdown, and list_themes, which serve different functions.

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 'pro opakované použití' implies when to use the tool (persisting a theme for later), but it provides no explicit when-not-to-use guidance or alternatives. It does not mention list_themes as the complement for retrieving saved themes.

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