hubspot-mcp-server

Overview Schema Source Related Servers Discussions Admin

create_marketing_email_draft

Create a marketing email as a draft in HubSpot without sending or scheduling. Specify the email name, subject, and template path to generate a review-ready draft.

Instructions

Create a marketing email in DRAFT state. Nothing is scheduled or sent.

Args: name: internal email name shown in the HubSpot listing. subject: subject line. template_path: path of the email template to render into, e.g. '@marketplace/theme/templates/email/base.html'. Required by HubSpot — widgets have nothing to render into without one. html_body: HTML for the template's main rich-text module. Convenience shortcut for widgets={"main_content": {"body": {"html": ...}}}. widgets: explicit widget tree when the template uses several modules. Keys are the module names defined in the template. Takes precedence over html_body for any overlapping key. from_name: sender display name. Portal default is used if omitted. reply_to: reply-to address. preview_text: preheader shown in the inbox next to the subject. language: ISO 639-1 code. Default 'en'. email_type: BATCH_EMAIL | AB_EMAIL | AUTOMATED_EMAIL. Default BATCH_EMAIL. subscription_type_id: HubSpot subscription type. Marketing emails cannot be sent without one, so set it if you know it. business_unit_id: only for portals using Business Units.

Input Schema

TableJSON Schema

Name	Required	Default
`name`	Yes
`subject`	Yes
`widgets`	No
`language`	No	en
`reply_to`	No
`from_name`	No
`html_body`	No
`email_type`	No	BATCH_EMAIL
`preview_text`	No
`template_path`	Yes
`business_unit_id`	No
`subscription_type_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Sep 24, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the DRAFT-only side effect, the precedence of widgets over html_body, and HubSpot's template requirement. It does not cover failure modes or permissions, but for a create operation the side-effect disclosure is strong.

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?

The docstring is longer than average, but every line maps to a distinct parameter or behavioral detail. The bulleted Args format is scannable, and the critical draft-only side effect is front-loaded. There is no filler or redundant boilerplate.

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?

The 0% schema coverage and absence of annotations are fully compensated: all input parameters, defaults, precedence rules, and the draft-only outcome are explained. Since an output schema exists, the description does not need to explain return values, and nothing essential is missing for calling this tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must supply all parameter meaning, and it does for all 12 parameters. It explains the relationship between html_body and widgets, provides a concrete template_path example, lists the valid email_type values, and clarifies portal and business-unit scoping.

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 opening sentence states the exact operation: create a marketing email in DRAFT state, which clearly identifies the resource and outcome. This distinguishes it from sibling tools like update_marketing_email_draft and publish_marketing_email. The second sentence reinforces that nothing is scheduled or sent.

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?

The description gives clear context for when to use this tool: when creating a new marketing email draft. The statement 'Nothing is scheduled or sent' tells the agent this is not the tool for sending or publishing. It does not explicitly name sibling alternatives such as update_marketing_email_draft or publish_marketing_email, so it stops short of full alternative routing.

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

Deploy Server