SmartPDF

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

No annotations are supplied, so the description carries the behavioral burden. It discloses useful operational details (defaults, the 6–72 font-size range, the public-URL requirement for file_url), but says nothing about whether the source file is modified, how the result is delivered, or any auth/limit constraints. With an output schema present, return values need not be explained, which keeps this at an adequate 3.

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 purpose line followed by five terse parameter lines, each front-loaded with the parameter name. No filler, no repetition of the schema structure.

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 single-purpose PDF mutation tool with an output schema and fully documented parameters, the definition is nearly sufficient. The remaining gap is guidance on when to choose this over watermark_pdf and whether the original file is preserved.

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: it documents all five parameters, names the three allowed position values, gives the font_size range 6–72 and default 12, the start_from default of 1, and an example prefix string. This fully covers what the bare schema omits.

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+resource: 'Добавляет номера страниц в PDF' (adds page numbers to a PDF), which is unambiguous. It does not differentiate itself from the nearest sibling watermark_pdf, which also stamps content onto pages, so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites (e.g. whether the PDF must be unprotected), and no mention of alternatives such as watermark_pdf for arbitrary stamps. Usage must be inferred entirely from the tool name and parameter list.

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

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

No annotations are provided, so the description carries the full behavioral burden and falls short. It notes that file_url is a public URL and that level defaults to medium, but says nothing about whether compression is lossy, how quality is affected, whether the output is a new file, or any permission/rate-limit constraints.

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 lines, front-loaded with the core action followed by one line per parameter. Every sentence earns its place with no 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?

An output schema exists, so return values need not be explained, and both parameters are covered. However, for a file-transforming tool with no annotations, the absence of any quality/lossiness note or usage context leaves a modest gap.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains file_url is a public URL and enumerates the level values low | medium | high with medium as the default. This adds meaning well beyond the bare string-typed schema, though it doesn't explain the tradeoff each level implies.

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

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

The description opens with a specific verb+resource ("Сжимает PDF-файл" / compresses a PDF file), which is unambiguous and clearly distinct from siblings like merge_pdfs or rotate_pdf. It does not explicitly name or differentiate itself from any sibling, but the action is self-evident from the name and first sentence.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling PDF tools. Usage is only implied by the tool name, so an agent gets no routing help beyond the purpose statement.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the original file is modified in place or a new PDF is returned, whether the deletion is reversible, what the output is, or any permission/URL accessibility limits beyond a bare 'public URL' note. For a destructive mutation tool this is a substantial 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?

Three short lines, front-loaded with the action, then one line per parameter. Nothing redundant and no 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?

An output schema exists, so return values need not be explained, and both parameters are documented. However, for a destructive mutation with zero annotation coverage, key facts — whether the source file is overwritten, and how the result is delivered — are missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: file_url is defined as a public URL to the PDF and pages as a 1-based list of page numbers to delete. The 1-based indexing is genuinely useful information not present in the schema, though boundary behavior (out-of-range or duplicate indices) is unstated.

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: 'Удаляет указанные страницы из PDF' (deletes specified pages from a PDF). An agent can immediately tell this apart from extract_pages or reorder_pages by the destructive 'delete' verb, though the description never names or contrasts any sibling 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?

There is no guidance on when to use this tool versus alternatives such as extract_pages (which keeps pages) or split_pdf, nor any prerequisites, exclusions, or ordering constraints. The agent must infer usage entirely from 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?

No annotations are provided, so the description carries the full burden. It implies a non-destructive read (output is a 'new PDF'), but says nothing about whether the source is modified, permission/auth requirements, size limits, or error behavior for out-of-range pages.

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 compact lines, front-loaded with the purpose and followed by per-parameter notes. No filler, though the terse style leaves no room for usage guidance.

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

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

An output schema exists, so return values need not be explained, and both parameters are covered. However, with no annotations and no usage or error guidance, the definition is only minimally complete for a tool that produces a derived file.

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: file_url is documented as a public URL of the PDF, and pages as a 1-based list whose order is preserved. This adds real semantics the bare schema lacks, though duplicate/out-of-range handling is unstated.

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: 'Извлекает выбранные страницы в новый PDF' (extracts selected pages into a new PDF). This distinguishes it from delete_pages, reorder_pages and split_pdf, though it does not name 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?

There is no explicit when-to-use or when-not-to-use guidance. With siblings like delete_pages, reorder_pages and split_pdf, the agent gets no criteria for choosing extract_pages over them; usage must be inferred from the verb alone.

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 does disclose the key trait that the result becomes non-editable and that form fields/annotations are baked in, which is useful consequence-level context. It does not cover permissions, input-file side effects, or processing behavior for a one-way transform.

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 lines, front-loaded with the action, then the behavioral consequence, then the parameter. No filler. Slightly terse rather than verbose; nothing is wasted.

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 single-parameter tool with an output schema (so return values need no explanation), the description covers purpose, effect, and the one parameter's requirement. Adequate; only minor gaps around processing/permission behavior remain and those are lower stakes here.

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% (file_url is a bare string), so the description must compensate, and it does: 'публичный URL PDF-файла' adds the crucial requirement that the URL must be publicly reachable and the file a PDF. That is meaningful semantics beyond the schema's untyped string.

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 and clarifies what flatten actually does mechanically: 'впечатывает поля форм и аннотации в страницы' (bakes form fields and annotations into the pages). This is unambiguous and no sibling overlaps (none of the other tools flatten). It stops short of explicitly distinguishing itself from siblings, so 4 rather than 5.

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

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

'идеально для госорганов и печати' (ideal for government agencies and printing) gives an implied use context for when the non-editable output matters, but there is no explicit when-to-use vs. alternative guidance (e.g., vs. protect_pdf or sign_pdf, which also touch form/annotation handling). Usage is inferred, not directed.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the balance is shared across all keys and MCP, that included requests are consumed before balance, and that the tariff month resets at included_resets_at — but it never states whether this is a safe read-only call or whether invoking it costs anything.

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 is front-loaded in the first clause, but the remainder is a dense block of field definitions that largely restate what the output schema already provides. It is informative but not tight.

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

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

An output schema exists, so return values need not be explained, yet the description adds genuinely useful semantics (shared balance, depletion order, reset timing). For a zero-parameter read tool this is close to complete, missing only an explicit statement of side-effect safety.

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 there is nothing for the description to disambiguate; baseline 4 applies. The field explanations describe outputs rather than 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 verb and resource ('Возвращает баланс API аккаунта') plus scope ('общий для всех ключей и MCP') and unit (rubles). It is unambiguously distinct from the PDF-manipulation siblings, though it never explicitly says so.

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 — an agent can infer you call it to check remaining credit or monthly spend. There is no explicit when-to-call guidance, no mention that the call itself may consume balance, and no reference to alternatives.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It usefully states that file_url must be a public URL and documents default page size and orientation, but it does not cover auth needs, rate limits, output handling, or side effects.

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

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

The description is front-loaded and minimal: purpose first, then parameter documentation. Every line earns its place and there is no repetition or 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?

For a simple conversion tool with an output schema, the description covers the purpose and all input parameters including defaults. It lacks usage routing among alternatives, but return-value details are unnecessary because an output schema exists.

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 fully compensates by documenting all three parameters: file_url as a public HTML URL, page_size with allowed values A4/A3/Letter and default A4, and orientation with portrait/landscape and default portrait.

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

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

The description states a specific verb and resource: converts an HTML file to PDF. It is immediately distinguishable from siblings like jpg_to_pdf, word_to_pdf, and pdf_to_word without needing to open the 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?

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The name and purpose imply the basic use case, but the description does not route the agent among the many conversion 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?

No annotations are provided, so the description carries the full burden. It does disclose two real behaviors — that each image becomes one page and that inputs must be publicly reachable URLs — but says nothing about ordering, size/limit constraints, authentication, or where the resulting file goes. Adequate disclosure for a simple converter, with visible 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 short sentences, front-loaded with the operation and followed by the page-mapping rule and parameter note. No filler; a slightly more explicit input/output framing sentence would make it 5.

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

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

An output schema exists, so return values need not be described. For a single-required-parameter conversion tool, the description covers the operation, the multi-image semantics, and the input format — everything needed to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it names file_urls and clarifies it is a list of public image URLs, which conveys both cardinality and accessibility requirements. Only the item type (string) is left to the schema.

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

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

States a specific verb and resource ('Конвертирует изображения (JPEG, PNG) в PDF'), which is clearly distinct from sibling converters like html_to_pdf, word_to_pdf, and the reverse pdf_to_jpg. The only wobble is the name 'jpg_to_pdf' being narrower than the stated JPEG+PNG scope. It identifies the operation without explicitly routing against siblings, so a 4 rather than 5.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named despite a large family of sibling conversion tools. The agent must infer that this is the image-input path from the description alone.

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 provided, the description carries the full behavioral burden. It usefully discloses that inputs must be public URLs, that at least two are required, and that input order determines page order. It says nothing about failure behavior (unreachable/encrypted/protected PDFs), size limits, or what happens if merging fails partway.

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 compact sentences with no filler, front-loading the core action followed by the ordering rule and the parameter constraint. Every clause adds 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?

An output schema exists, so return values need not be described. For a simple single-parameter merge tool the description covers the action, ordering behavior, and input constraints. The remaining gap is error/failure handling for bad or inaccessible URLs, which is minor given the tool's simplicity.

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

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

Schema description coverage is 0%, so the description must compensate for the single undocumented parameter — and it does: file_urls is defined as a list of public PDF URLs with a minimum of 2 entries, and the ordering semantics ('order of files = order of pages') give real meaning the schema cannot convey. It stops short of format details such as whether the array must be non-empty strings or URL scheme restrictions.

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

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

The description states a specific verb and resource ('Объединяет несколько PDF в один' — merges several PDFs into one), which is unambiguous and clearly distinct from siblings like split_pdf or extract_pages. It does not explicitly name alternatives, but the operation itself cannot be confused with any 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?

Usage is implied rather than stated: the agent can infer this is the tool for combining files, and the 'minimum 2 files' note hints at a precondition. However, there is no explicit when-to-use vs. when-not-to-use guidance, no mention of alternatives such as split_pdf, and no prerequisites for the operation.

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 meaningful work: it discloses the invisible-text-layer side effect, the 100-page cap, and the cost model ('1,25 ₽ за каждые 10 страниц'). It omits error/permission behavior, but the operational traits it does disclose are exactly the ones an agent needs.

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?

Purpose is front-loaded, followed by limits/cost and then per-parameter notes. Every sentence contributes; the only slight inefficiency is splitting parameter hints into a trailing block rather than integrating them tightly.

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

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

An output schema exists so return values need no explanation, and the description supplies limits, pricing, the large-file workflow, and both parameter meanings. It leaves auth/error conditions unstated, which is a modest gap for a paid conversion 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?

Schema coverage is 0%, so the description must document both parameters, and it does: file_url is described as a public PDF URL and languages is described with an example and a default ('русский + английский'). Minor gap is that 'public URL' accessibility constraints are not spelled out.

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+resource ('Распознаёт текст в сканированном PDF (OCR)') and adds the concrete effect ('Добавляет невидимый текстовый слой'), which separates OCR from the extraction siblings like pdf_to_txt. An agent can identify the operation without opening the 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?

Gives clear context (scanned PDFs), an explicit size boundary ('До 100 страниц за раз') and names the alternative for overflow ('больший файл сначала разделите split_pdf'). It stops short of any when-not guidance versus related convert/extract tools, so it is strong but not exhaustive.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose useful output behavior via the layout modes ('per-table' vs 'single-sheet') and implies only tables are extracted, but it omits permissions, size/page limits, and what happens when no tables are found.

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?

Purpose is front-loaded in the first sentence, followed immediately by the two parameter explanations. Every line earns its place with 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?

For a simple two-parameter converter with an output schema handling return values, the description covers purpose and both parameters adequately. It leaves gaps around error conditions and scanning/OCR scenarios, but nothing essential to calling it correctly is missing given the output schema exists.

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 largely does: it explains file_url must be a public URL and that layout offers 'per-table' (default) or 'single-sheet'. Both parameters gain meaning beyond the type-only schema, though edge cases (e.g. invalid URL, table-less PDF) are unaddressed.

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: it extracts tables from a PDF and writes them to an .xlsx file. The word 'tables' usefully scopes the operation against generic PDF converters in the sibling list. It does not explicitly name an alternative, but the purpose is unmistakable.

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 statement of when to use this tool versus siblings like pdf_to_txt, pdf_to_word, or pdf_to_pptx, nor any prerequisites (e.g. PDF must contain real tables, not scanned images requiring ocr_pdf). Only the parameter formatting is addressed, not usage conditions.

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 a key behavioral trait: the result is a ZIP archive with page-N.jpg naming, plus the allowed dpi values. It omits any notes on permissions, file size limits, or how multi-page PDFs are chunked beyond the naming convention.

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, front-loaded lines: purpose and output first, then the two parameters. No filler, nothing repeated from the schema.

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

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

An output schema exists, so return-value explanation is not required, and the description still notes the ZIP shape. Purpose, output, and both parameters are covered; only explicit usage/routing guidance is missing for a simple 2-param converter.

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: file_url is clarified as a public URL to the PDF, and dpi's valid values (72 | 150 default | 300) are enumerated with the default. Both parameters gain meaning beyond 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+resource ('Конвертирует страницы PDF в JPEG') and even names the output artifact (ZIP archive of page-N.jpg), so it is immediately distinguishable from the reverse sibling jpg_to_pdf and the other converters.

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 says what the tool does but gives no when-to-use guidance, prerequisites, or routing against the many sibling converters (pdf_to_txt, pdf_to_pptx, etc.). Usage is only inferable from the name and output statement.

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. It does disclose a real behavioral trait — one slide is produced per PDF page — which is genuinely useful. However, it says nothing about permissions, file-size limits, processing time, or what happens with scanned/image-only PDFs.

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?

Very tight: conversion behavior and page-to-slide mapping come first, and the parameter note follows. Every sentence carries information; no 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?

For a simple single-parameter conversion tool with an output schema already declared, the description covers the transformation semantics and the parameter meaning. Only secondary details (input constraints, failure modes) are missing, which is acceptable at this complexity.

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

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

Schema description coverage is 0% and the single parameter is documented only as a bare string, so the description must compensate. It does add meaning by specifying that file_url is a public URL of the PDF file, but omits any format, reachability, or size constraints 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?

States a specific verb and both source and target formats ('Конвертирует PDF в PowerPoint (.pptx)'), which clearly separates it from siblings like pdf_to_word, pdf_to_jpg and the reverse pptx_to_pdf. An agent can pick this tool without opening the 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?

No when-to-use, when-not, or prerequisite guidance is given. The name makes the general intent obvious, but there is no mention of file-size limits, whether the input must be a text-based PDF, or how this differs in applicability from e.g. ocr_pdf before conversion.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add real behavioral context: UTF-8 encoding, per-page text layout, paragraph/column blocks, and per-word coordinates. It omits permission needs, size limits, and crucially whether scanned PDFs need OCR first — a significant gap for a text-extraction tool with zero annotation coverage.

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 parameter definitions in a compact structured list. Every line earns its place; the mode sub-bullets are informative rather than 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?

An output schema exists, so return-value explanation is not required. For a two-param file-producing tool the definition is mostly adequate, but the absence of any OCR/scanned-PDF guidance leaves a real routing gap when sibling ocr_pdf exists.

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: file_url is defined as a public URL of the PDF, and each of the three mode values is explained with its output shape. Minor gap — it does not clarify mode's default placement alongside the schema's default, but coverage of both params is solid.

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: extracts text from a PDF into a .txt file, and pins the encoding (UTF-8). This clearly separates it from pdf_to_word, pdf_to_excel, and pdf_to_pptx, which produce different formats. An agent can identify the tool's job without opening the 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?

The mode enumeration implies when to choose text vs blocks vs words, which is useful implied guidance. However, it never states when this tool is the wrong choice — notably it does not point to ocr_pdf for scanned/image PDFs, which is the single most important routing decision here. Usage is implied, not explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses only the output format. It says nothing about file size limits, conversion latency/async behavior, failure modes (e.g. scanned/non-text PDFs), or whether the output is returned as a URL or inline, which matters for a conversion tool.

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

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

Two short lines, front-loaded with the action and output format, and the parameter note follows immediately. No wasted words, though the note is terse enough to border on under-specification.

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 single-parameter conversion tool with an output schema present, the description covers the purpose and the one input's required nature, which is nearly sufficient. The gap is the absence of any behavioral caveats around failure or output handling, but returns need not be explained given the output schema.

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

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

With schema description coverage at 0%, the description is the only source of parameter meaning, and it does supply it: file_url is a 'публичный URL PDF-файла' (a public URL, not a local path or upload ID). That constraint is genuinely useful beyond the bare string type in the schema.

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

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

Specific verb+resource conversion ('Конвертирует PDF в редактируемый Word-документ') with the output format (.docx) named explicitly, which cleanly separates it from siblings like pdf_to_txt or pdf_to_pptx. It never names a sibling (e.g. word_to_pdf as the reverse operation) for differentiation, so it stops short of a 5.

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

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

No when-to-use guidance, no prerequisites, and no reference to alternative conversion tools. The agent is left to infer usage entirely from the purpose statement.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one real constraint beyond the schema: the file must be reachable at a public URL. However, it says nothing about file size limits, processing time, async behavior, or authentication expectations for a remote conversion service.

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 compact lines, with the action front-loaded and the parameter note second. Every clause carries information; nothing is padded or redundant.

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 an output schema present, return values need not be explained, and the single input is adequately covered. Still, for a zero-annotation conversion tool that hands work to an external service, the description omits operational limits and failure conditions an agent would want before invoking 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 0% and the single parameter has no description in the schema, so the description must compensate. It does: 'file_url: публичный URL PPTX-файла' clarifies both the meaning (URL to the PPTX) and the accessibility requirement (public), which the bare 'string' type does not convey.

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

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

The description states a specific verb and resource ('Конвертирует презентацию PowerPoint ... в PDF') and names both accepted input extensions (.pptx/.ppt). The direction of conversion implicitly separates it from the sibling pdf_to_pptx, though it never explicitly contrasts with the other converter tools (word_to_pdf, html_to_pdf, xlsx_to_pdf).

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

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

Usage is only implied by the declared formats: an agent can infer it should be called when it holds a PPTX and wants a PDF. There is no explicit when-to-use statement, no prerequisites, and no routing guidance relative to the other 20+ conversion/pdf tools.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the AES-256 encryption level and the distinction between user and owner passwords, but says nothing about permissions granted/restricted, whether an already-encrypted file is rejected, or what the operation returns/produces.

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 purpose sentence followed by a tight three-line parameter glossary. No filler, no repetition of structured fields beyond what the 0% schema coverage requires.

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

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

An output schema exists, so return values need not be described. However, for a file-mutating tool with no annotations, the description omits whether the result is a new file/URL or an in-place change, and whether permissions are configurable.

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: all three parameters are annotated (public URL for file_url, open password for user_password, owner password marked optional for owner_password). It does not explain how owner vs. user passwords affect permission restrictions, which is the one remaining gap.

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 ('Защищает PDF паролем') plus the encryption standard (AES-256), which is enough to distinguish it from the sibling 'unlock_pdf' by implication. It does not explicitly name the opposite-operation sibling, so it falls just short of a 5.

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

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

There is no statement of when to choose this tool versus e.g. unlock_pdf or sign_pdf, and no prerequisites (e.g. whether the PDF must be unprotected first, or whether an existing password is needed). Usage is only inferable from the name and parameter list.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it is silent on key mutation traits: whether the original file is overwritten or a new PDF is returned, and whether the operation is non-destructive. It discloses only the basic action.

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 lines, front-loaded with the action followed by the two parameter notes. Nothing is padded and each line adds 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?

The output schema covers return values and both params are described, but for an un-annotated file-mutating tool the definition omits whether the source is modified in place or a new file is produced, leaving a meaningful gap 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?

With 0% schema description coverage the description must compensate, and it does define both parameters: file_url as a public PDF URL and new_order as a 1-based ordering with a concrete example ([3,1,2]). It stops short of stating whether new_order must be a full permutation of all pages or may omit/duplicate pages.

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 ('Переупорядочивает страницы PDF' / reorders PDF pages), which is enough to distinguish it from delete_pages, extract_pages, and rotate_pdf by the operation performed. It is clear but never explicitly contrasts itself with those siblings.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance at all. The description only states what the tool does, leaving an agent to infer that reordering is the intended selection versus, say, merging or splitting.

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

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

No annotations are provided, so the description carries the full burden. It is a mutation tool, yet nothing is said about whether the original file is overwritten or a new one is returned, permission/auth requirements, size limits, or rate limits. Only parameter syntax 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?

Front-loaded one-line purpose followed by a compact parameter list with zero filler. Every line earns its place, though the parameter list reads more like schema restatement than prose guidance.

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

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

An output schema exists so return values need no explanation, and all three parameters are covered. Still, for a mutation tool with no annotations, the description omits behavioral facts an agent needs (overwrite vs. new file, file-size or URL-access constraints).

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: it explains file_url is a public URL, pages is a 1-based list or "all", and constrains angle to 90|180|270 — a constraint absent from the schema. Only the distinction between the array and string forms of pages is left slightly implicit.

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 (rotates PDF pages), which is clearly distinct from siblings like reorder_pages or delete_pages. However, it never explicitly contrasts itself with those siblings, so the agent must infer the difference.

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 contains no guidance on when to use this tool versus alternatives such as reorder_pages or flatten_pdf, and no prerequisites (e.g. that the file must be reachable via a public URL). It only lists parameters.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral trait that the signature is visual text (not a digital signature), which is valuable, but it omits whether the PDF is mutated in place, whether auth/quota is needed, or what happens on repeated calls.

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 purpose sentence followed by a compact parameter glossary; front-loaded and free of filler. The terse list style slightly reduces readability but is appropriately sized for seven parameters.

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 7 parameters, 0% schema coverage, and no annotations, the description covers parameter meaning but leaves behavioral and usage gaps (mutation semantics, relevance vs watermark_pdf). An output schema exists, so return values need not be explained.

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: it documents file_url (public URL), signature_text, page (1-based), x/y coordinates on 0.0–1.0, and width/height block size on 0.0–1.0. This adds units and coordinate semantics absent from the bare schema, though it does not explain the defaults or which two are required.

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

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

The description states a specific verb and resource: it adds a visual text signature to a PDF page. The word 'визуальную текстовую' usefully distinguishes it from a cryptographic/digital signature, though it never explicitly contrasts with the sibling watermark_pdf, the closest neighbor.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as watermark_pdf. The agent is left to infer that this is a decorative overlay rather than a legal/cryptographic signing operation.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the result is a ZIP archive and that file_url must be a public URL, but it omits other relevant traits such as permissions, rate limits, or whether the original file is untouched.

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

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

The description is front-loaded with purpose and output, then documents parameters compactly. Every sentence earns its place with 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 simple three-parameter schema, no annotations, and an existing output schema, the description is nearly complete for invocation. It clearly explains parameter meanings and the output format, though it still lacks sibling differentiation and broader operational context.

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

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

Schema description coverage is 0%, and the description fully compensates by documenting all three parameters: file_url as a public PDF URL, mode values including the default, and the ranges format with an example.

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: 'Splits PDF into parts' and names the output format as a ZIP archive of PDF files. It does not explicitly distinguish the tool from close siblings such as extract_pages, so it falls short of a 5.

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

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

There is no guidance on when to use split_pdf versus alternatives like extract_pages, delete_pages, or merge_pdfs. The mode options describe how to configure the split but not the tool-selection context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says what the operation does but not whether the output is a new decrypted file, where it is returned, whether the original is preserved, or what happens on a wrong password. For a mutation-style tool with zero annotation coverage this is a meaningful 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?

Front-loads the operation in one sentence, then documents the two parameters in a compact list. Every line carries information; it is slightly terse rather than padded, which is appropriate here.

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

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

An output schema exists, so return values need not be explained. However, for a tool with no annotations and no sibling-differentiation, the description leaves out error behavior and output handling, making it only minimally complete.

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: it defines file_url as the public URL of the protected PDF and password as the password used to remove protection. This adds real meaning beyond the bare typed properties, though it omits format constraints such as URL scheme.

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: removes password protection from a PDF. It is clearly distinguishable from siblings like protect_pdf or flatten_pdf. It does not explicitly name the inverse tool (protect_pdf) to differentiate, so it falls short of a 5.

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

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

No guidance on when to use this versus alternatives such as protect_pdf, nor any prerequisites (e.g. that the PDF must actually be encrypted, or that the password must be correct). The agent must infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies an additive write, but never states whether the watermark overwrites existing content, whether it is reversible, what permissions or file-state conditions apply, or any rate limits. Output schema exists so return format need not be covered, but the mutation/authorization profile is absent.

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?

Purpose is front-loaded in one sentence, followed by a tight parameter reference. No filler, no repetition. It is dense but readable, with each line earning 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?

For a mutation tool with no annotations, the definition is only adequate: it covers inputs thoroughly but omits any behavioral/operational context (destructiveness, prerequisites, error conditions). The existing output schema relieves it of explaining return values, which keeps this from being lower.

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 fully — and it does. Every parameter is documented with meaning, defaults ('по умолчанию 0.3', 45), value ranges (0.0–1.0), the enumerated position options, and the text/image_url mutual exclusion.

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+resource ('adds a watermark to PDF pages'), which clearly distinguishes it from siblings like add_page_numbers, protect_pdf, and flatten_pdf. It's clear and unambiguous, though it never explicitly names an alternative tool to route away from.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The one piece of usage context provided is the mutual exclusivity between 'text' and 'image_url' ('excludes image_url' / 'excludes text'), which is useful but is a parameter constraint rather than selection 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?

No annotations are provided, so the description carries the behavioral burden. It does disclose one important constraint - file_url must be a publicly accessible URL - which is real behavioral context, but it says nothing about file size limits, processing latency, failure modes, or whether the output is a download link. An output schema exists, so return format need not be explained, but other behavioral traits are missing.

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

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

Two short lines, front-loaded with the verb and resource, followed immediately by the only parameter's meaning. 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?

For a single-parameter conversion tool with an output schema already describing the return, the description covers what an agent needs to invoke it correctly: direction, accepted formats, and the public-URL requirement. Missing size/limit and failure details keep it short of 5.

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

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

Schema description coverage is 0% and the single parameter gets its own explanation: file_url is the public URL of the Word file. That adds genuine meaning the bare string-typed schema does not convey, specifically the public-accessibility requirement. It does not specify accepted URL schemes or size constraints, keeping it below 5.

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

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

The description names a specific verb and resource (converts a Word .doc/.docx document to PDF) and pins the accepted input formats, which distinguishes it from the many other *_to_pdf siblings. It stops short of explicitly naming the reverse sibling (pdf_to_word) or other converters, so it is clear but not sibling-differentiating.

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

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

Usage is only implied by the stated conversion direction and accepted extensions (.doc/.docx); there is no explicit when-to-use, when-not-to-use, or route to an alternative such as html_to_pdf or jpg_to_pdf. An agent can infer the fit from the format constraint, but nothing is 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It only notes that file_url must be a public URL; it does not state file-size limits, authentication requirements, synchronous/asynchronous behavior, or other operational constraints.

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 the action and followed by the only parameter's meaning. No filler or redundant explanation.

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 one-parameter conversion tool with an output schema, the description covers the purpose and required input adequately. It is missing explicit usage guidance and operational limits, but the core invocation is clear.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter. It does so by explaining that file_url is the public URL of an XLSX file, which adds useful format and access semantics beyond the bare string type.

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

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

The description states a specific verb and resource: converting Excel (.xlsx/.xls) to PDF. It clearly distinguishes this tool from siblings like pdf_to_excel, word_to_pdf, and html_to_pdf by naming both the source and target formats.

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 conversion direction, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternative conversion tools. An agent can infer the use case, but the description does not route between siblings.

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