Skip to main content
Glama
BatuhanCakmakk

LaserPDF

by BatuhanCakmakk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Rotate pages

rotate_pages
Idempotent

Rotate all or selected PDF pages clockwise by 90, 180, or 270 degrees to correct sideways or upside-down scans, saving changes to a new PDF.

Instructions

Rotates every page, or the chosen pages, clockwise by 90, 180 or 270 degrees and writes the whole document to a new PDF. Use it for sideways or upside-down scans; page content is not altered, only its display rotation, which is added to any rotation the page already has. The original is not changed, and an existing output file is only replaced with overwrite: true. Fails with a message for an invalid page range and for encrypted PDFs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path of the PDF.
pagesNoPages as 1-based numbers and ranges, e.g. "1-3,5". All pages when omitted; a page outside the document is an error.
outputYesAbsolute path of the new PDF. If the file exists, the call fails unless overwrite is true.
degreesYesClockwise turn added to the current rotation.
passwordNoPassword, if the PDF is encrypted. Without it an encrypted PDF cannot be opened; with it, it can be read, but tools that write a new PDF cannot save it.
overwriteNoAllow replacing an existing file (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.9
    • addedInput schema / properties / degrees / description
      Added value: +"Clockwise turn added to the current rotation."
    • changedInput schema / properties / output / description
      Previous value: -"Absolute path of the PDF to write."New value: +"Absolute path of the new PDF. If the file exists, the call fails unless overwrite is true."
    • changedInput schema / properties / pages / description
      Previous value: -"Pages, e.g. \"1-3,5\" (1-based). All pages when omitted."New value: +"Pages as 1-based numbers and ranges, e.g. \"1-3,5\". All pages when omitted; a page outside the document is an error."
    • changedInput schema / properties / password / description
      Previous value: -"Password, if the PDF is encrypted."New value: +"Password, if the PDF is encrypted. Without it an encrypted PDF cannot be opened; with it, it can be read, but tools that write a new PDF cannot save it."
  2. First observedv1.0.6

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: rotation is additive to existing page rotation, content is not altered, the original is untouched, an existing output is replaced only with overwrite:true, and it fails with a message for invalid page ranges and encrypted PDFs. This is exactly the mutation-safety context the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) cannot convey on their own.

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

Conciseness5/5

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

Three front-loaded sentences with zero filler: purpose and parameter range first, then the use case and rotation semantics, then side effects and failure modes. Every clause carries information an agent needs.

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

Completeness4/5

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

For a mutation tool with no output schema, the description covers side effects, overwrite behavior, additive rotation, encryption limits, and error conditions. The only gap is what the call returns on success (e.g. the new file path), which the agent must infer.

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

Parameters3/5

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

Schema description coverage is 100%, and all six parameters are documented in the schema, including the enum and the overwrite/password semantics. The description's parameter-level statements (added rotation, invalid page range error, overwrite-only replacement) largely restate the schema rather than adding new syntax or format detail, so the baseline 3 applies.

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 (rotates), resource (pages of a PDF), scope (all pages or a chosen subset), parameter range (90/180/270 clockwise), and the outcome (writes a new PDF). Nothing among the siblings overlaps: none of merge/split/extract/compress rotate pages.

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?

Gives an explicit trigger scenario: 'Use it for sideways or upside-down scans'. That tells the agent when the tool applies. It stops short of naming alternatives or exclusions (e.g. when not to use it vs. pdf_to_images or extract_pages), so it lands at 4 rather than 5.

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

Deploy Server

Other Tools