erp2pdf-studio-mcp

Overview Schema Source Related Servers Discussions Admin

create_email_template

Builds Odoo email templates with subject/body expressions, model binding, and optional PDF attachment for automated record-based sending.

Instructions

Create an email template. Subject and body use the PDF templates' expressions: {{ expr }} prints a value HTML-escaped, {{{ expr }}} inserts it as cleaned HTML. Use inline styles and tables (email clients). {{ odoo_url }} is the connected Odoo's https address: {{ odoo_url }}/logo.png?company={{ company_id.id }} is the company logo. attach_template_id = a PDF template to attach when sent.

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": {
      "name": "<name>"
    },
    "name": "create_email_template"
  }
}

Input Schema

Name	Required	Default
`name`	Yes
`subject`	No
`body_html`	No
`bind_model`	No	sale.order
`description`	No
`attach_template_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Oct 26, 2026

TDQS

B3.2/5.0

Behavior3/5

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

No annotations exist, so the description carries the full behavioral burden. It usefully explains the body templating dialect ({{ }} escaping vs {{{ }}} raw HTML), the {{ odoo_url }} convention, and the meaning of attach_template_id, but says nothing about permissions, whether the template is immediately active/sendable, or what happens after creation.

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?

Purpose is front-loaded in the first sentence, followed by dense, non-repetitive authoring rules. Slightly compressed to the point of terseness, but no sentence is wasted.

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?

For a 6-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers the body/attachment side well but omits bind_model semantics and the return value (e.g., the new template's id), which an agent needs to chain a preview or update call.

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 coverage is 0%, so the description must compensate and it does so partially: it explains the subject/body expression syntax and attach_template_id. It leaves 'name', 'description', and especially 'bind_model' (a 4-value enum) entirely unexplained, so the agent must guess what binding a template to a model implies.

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 opens with a specific verb and resource ('Create an email template'), clearly distinguishing it from sibling update_email_template/delete_email_template by name alone. It never explicitly contrasts usage against create_template or create_from_starter, so it stops short of full sibling differentiation.

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 statement of when to choose this over create_template, create_from_starter, or duplicate_template. The guidance given ('use inline styles and tables') is about how to author the body, not when/when-not to call the tool.

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