Skip to main content
Glama
gray-wilbee

fub-mcp

by gray-wilbee

update_template

Update an existing email template's name, subject, and body. Merge field placeholders are saved as-is for later personalization when sending.

Instructions

Update an email template. (PUT /templates/{id}) FUB templates support %merge_field% placeholders that FUB substitutes when a human actually sends the template (not by this tool — this just saves the template text as-is). Reference: Contact: %contact_name% (full), %contact_first_name%, %contact_last_name%, %contact_email%, %contact_phone%, %contact_address%, %contact_street%, %contact_city%, %contact_state%, %contact_zipcode%, %contact_country%, %contact_rels_first_name% (first names of the contact's linked relationships, e.g. spouse/family added via peopleRelationships). Company (from Admin > Company settings): %company_name%, %company_phone%. Agent / Lender / Sender — same field set, swap the prefix (agent = assigned agent, lender = assigned lender, sender = whoever is actually sending this particular message, which may be neither): %agent_name%, %agent_first_name%, %agent_last_name%, %agent_email%, %agent_phone% (the FUB-assigned calling/texting number), %agent_mobile_phone% (their real/personal number), %agent_merge_field_1% (one free-form field each user sets in My Settings > Other Settings > Edit User Merge Field — commonly a booking link or social profile). ⚠️ %_phone% vs %mobile_phone% is genuinely ambiguous — always confirm with the user which one they mean before using either; picking wrong sends the recipient the wrong callback number. Inquiry (how the contact became a lead, e.g. clicking "Get more info" on a listing site): %inquiry_address%, %inquiry_address_url% (only if the lead source provided one), %inquiry_address_preview% (renders an HTML photo+link box — email only, meaningless in a plain-text SMS template). Recently viewed (populated only when synced with a provider that shares property views): %viewed_address%, %viewed_address_url%, %viewed_address_preview%, %last_5_preview% (up to 5 as HTML boxes, email only). Other: %source_name% (lead source, e.g. "Zillow" — "I saw your inquiry on %source_name%"), %greeting_time% ("Morning"/"Afternoon"/"Evening" based on send time — "Good %greeting_time%, %contact_first_name%"), %tour_time% (populated if the contact scheduled a tour via Zillow). Custom fields: %custom% (e.g. %custom_website%, %custom_birthday%, %custom_spouse_name%). Call list_custom_fields to confirm a field exists — but note its API name (e.g. customBirthday, camelCase) and its merge-field name (%custom_birthday%, snake_case) are different spellings of the same field, and there's no API that returns the merge-field spelling directly, so confirm the exact form with the user (or FUB's own Merge Fields dropdown in the template composer) if it's not obvious from the label. A merge field with no value for a given contact is simply left blank when the template is used — not an error, not a visible placeholder.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
bodyYesThe new body for the email template.
nameYesThe new name for the email template.
subjectYesThe new subject for the email template.
extraBodyNoExtra raw JSON body fields not explicitly listed above — e.g. custom.* fields when creating/updating people or deals. Keys and values are sent as-is.
extraQueryNoExtra raw query parameters not explicitly listed above — e.g. FUB custom field filters like custom.ClosingDate on /people or /deals. Keys and values are sent as-is.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.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 burden and it does important work: it explicitly states that FUB substitutes merge fields only when a human sends the template, 'not by this tool,' and that empty merge fields are left blank rather than causing errors. It omits details like overwrite semantics or return value, but the core no-side-effect behavior is clearly disclosed.

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?

The description is long, but it is front-loaded with the core purpose and then organized into clear categories: contact, company, agent, inquiry, viewed, other, and custom fields. Each section is directly relevant to constructing valid template content, so the length is justified rather than padding.

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?

Given the complexity of FUB merge fields and the absence of both annotations and an output schema, the description covers the hardest part comprehensively: the full merge-field catalog, the custom-field naming mismatch, and a pointer to list_custom_fields. It does not cover return values or explicit alternative routing, but an agent has enough to invoke the tool correctly.

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?

Schema coverage is high at 83%, so the baseline is 3. The description adds real value by enumerating valid merge-field syntax for the body and subject parameters and warning about the ambiguous %*_phone% vs %*_mobile_phone% distinction. It does not add meaning to id, extraBody, or extraQuery, but the schema already describes those well enough.

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 opening sentence names a specific verb and resource: 'Update an email template.' It also identifies the HTTP endpoint and clarifies that this tool only saves template text, not sends messages, which helps distinguish it from send/merge operations. It does not explicitly name sibling alternatives, so it falls just short of a 5.

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?

The description never says when to use update_template instead of create_template, update_text_message_template, or post_templates_merge. It gives useful content-level guidance around merge fields, but that is about what to put in the body/subject, not about tool selection.

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