erp2pdf-studio-mcp

Overview Schema Source Related Servers Discussions Admin

create_from_starter

Generate a new template from a pre-selected starter layout like an invoice or quotation. Adjust its design using specific styles, themes, and fonts.

Instructions

Create a template from a starter layout (same as Studio's New template dialog). style picks the look (default classic): folder = light band with a folder tab, wave = dark wave header, diagonal = dark band with a slanted edge, sidebar = coloured column, bigtotal = the amount to pay set large. Every colour is a theme reference, so update_template(layout_set={"theme": {...}}) rebrands it. theme picks a palette and fonts at creation: a palette key ("ocean"), or {"palette": "ocean", "fonts": "editorial", } (list_starters lists presets.palettes and presets.fonts). Classic reuses the shared 'Company header'/'Company footer' parts (created on first use); the bold styles draw their own letterhead. model is only for the blank starter.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "starter": "<starter>",
      "name": "<name>"
    },
    "name": "create_from_starter"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`model`	No
`style`	No
`theme`	No
`footer`	No
`header`	No
`starter`	Yes
`date_format`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.2.1Oct 26, 2026

addedInput schema / properties / style

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "classic",
+        "folder",
+        "wave",
+        "diagonal",
+        "sidebar",
+        "bigtotal",
+        "light",
+        "boxed",
+        "striped",
+        "bubble",
+        "elegant"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Style"
+}

addedInput schema / properties / theme

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Theme"
+}

First observedv0.4.0Oct 26, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the whole burden and does disclose a non-obvious side effect: classic reuses the shared 'Company header'/'Company footer' parts that get created on first use, while bold styles draw their own letterhead. That is exactly the kind of hidden mutation an agent needs. Still silent on permissions, failure modes, or what the call returns.

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?

Front-loads the core action, then spends its length on genuinely load-bearing detail (style meanings, theme shapes, side effects). The theme sentence with its nested parenthetical and inline '<theme keys>' is the one dense, hard-to-parse spot, but there is little outright waste.

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 an 8-param, no-annotation, no-output-schema creation tool this covers the essentials: what gets created, how styling and theming work, and the shared-parts side effect. The gaps are the five unlisted style values and the four undocumented parameters, which an agent would have to guess at.

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 0% across 8 params, so the description must compensate, and it does well for style, theme, and model. However the enum lists 11 styles and only 6 are explained (light, boxed, striped, bubble, elegant are unexplained), and name, header, footer, and date_format get no mention at all. Partial compensation, not full.

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?

Opens with a specific verb+resource ('Create a template from a starter layout') and anchors it to a familiar workflow ('same as Studio's New template dialog'). It also implicitly separates itself from create_template by noting that 'model' is only for the blank starter, so an agent can tell which creation tool fits.

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 real usage context: which style string selects which look, that theme accepts either a palette key or an object, and that list_starters enumerates presets.palettes/presets.fonts. It also points at update_template for later rebranding. It never states when to prefer this over create_template or preview_starter, so no explicit exclusion guidance.

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