Skip to main content
Glama

pdf_to_pdfa

Конвертирует PDF в PDF/A — формат долговременного хранения (архивы, суды, госорганы). file_url: публичный URL PDF-файла. version: 1 (PDF/A-1b) | 2 (PDF/A-2b, по умолчанию) | 3 (PDF/A-3b).

Input Schema

NameRequiredDescriptionDefault
versionNo2
file_urlYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior2/5

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 says almost nothing beyond the format conversion. It does not state whether the source file is preserved, permission/auth requirements, file-size limits, or how the converted artifact is returned, leaving key operational traits undisclosed.

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

Conciseness4/5

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

Three short lines: purpose first, then the two parameters, each earning its place with no filler. Slightly terse on behavior, but well front-loaded and waste-free.

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

Completeness3/5

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 params are documented. For a tool with zero annotation coverage, though, the description leaves behavioral gaps (source preservation, limits, error handling) that an agent would want before invoking.

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

Parameters4/5

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 'публичный URL' and version is unpacked into 1/2/3 mapped to PDF/A-1b/2b/3b with the default noted. This adds meaningful semantics the bare schema (no enums) does not carry.

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

Purpose5/5

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

States a specific verb and resource ('Конвертирует PDF в PDF/A') and immediately clarifies the target format's purpose (long-term archival). An agent can distinguish this from sibling conversions like compress_pdf or pdf_to_word without opening any schema.

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

Usage Guidelines4/5

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

Provides clear use-case context ('архивы, суды, госорганы'), which tells the agent when this conversion is appropriate. However, it names no explicit alternatives or exclusion conditions, so routing guidance is contextual rather than prescriptive.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.