Skip to main content
Glama
Sign In
erp2pdf-studio-mcp

erp2pdf-studio-mcp

by c4pointer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_capabilities

Fetch the layout capabilities and validation rules before designing templates: slot kinds, allowed style keys, paint formats, path recipes, fonts, page sizes, and limits.

Instructions

Read this before designing. Everything a layout can hold, from the same rules the validator applies: slot kinds and their keys with types and allowed values (text: letterSpacing, lineHeight, textTransform, valign, bgColor...; image: mask, grayscale; every slot: opacity, shadow, rotation, blendMode), the paint format (hex, theme., or a linear/radial gradient object), the path kind (free vector drawing: viewBox + paths[{d, fill, gradient, stroke, ...}]), page background, theme keys, bundled fonts, page sizes, limits, and ready path_recipes (folder tab, wave, diagonal band, chevron, hexagon, blob, corner arc) to copy into a path slot.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_capabilities"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose key behavioral facts: this is a read-only reference ('Read this'), it is authoritative because it comes from the same rules the validator applies, and it includes limits and ready-made recipes. It stops short of stating output size or format, which matters for a bulk reference dump an agent will pay context for.

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

Conciseness3/5

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

The lead instruction is well front-loaded, but the remainder is one dense run-on sentence threaded with nested parentheticals ('text: letterSpacing, lineHeight...; image: mask, grayscale; every slot: opacity...'), which is hard to scan. The details are mostly load-bearing since no output schema exists, but the packaging costs readability.

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

Completeness5/5

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

With no annotations and no output schema, the description must fully explain what comes back, and it does: it covers every category of returned reference data down to specific keys and allowed values, plus path_recipes for immediate reuse. An agent knows what it will get and why before calling.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description's job here is to describe returns instead, which it does at length.

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?

The description opens with a direct instruction ('Read this before designing') and then enumerates precisely what the resource contains: slot kinds and their keys, paint format, path kind, page background, theme keys, fonts, sizes, limits, and path_recipes. That enumeration lets an agent distinguish it from siblings like get_fields, get_values, or validate_layout 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?

Timing is explicit: 'Read this before designing.' It also implies its relationship to validate_layout by noting it derives 'from the same rules the validator applies,' so an agent understands this is the reference the validation step enforces. No explicit when-not-to-use or named-alternative routing is given, which keeps it below a 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