Skip to main content
Glama

sign_pdf

Добавляет визуальную текстовую подпись на страницу PDF. file_url: публичный URL PDF-файла. signature_text: текст подписи. page: номер страницы (с 1). x, y: координаты (0.0–1.0). width, height: размер блока (0.0–1.0).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
pageNo
widthNo
heightNo
file_urlYes
signature_textYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.