Skip to main content
Glama

List Email Merge Variables

emails_variables_list
Read-only

Returns the merge-tag variable catalog an email send can substitute: built-in tags plus the app's CRM custom fields. Each entry has name, sample text, and related metadata. Pass optional shop_domain to swap the store variables' generic samples for that store's real values, empty where the store has none (unknown stores fall back to samples). Each variable has sample_source: store when its sample is that store's own value, placeholder for a generic sample (every variable without shop_domain, an unknown store, and the contact, event and custom field variables). With shop_domain, the root also has store_found (false when Meridian does not know the store). Takes the app_id returned by apps_list. Requires emails.view; a store's real values also require crm.merchants.view.

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

Input Schema

NameRequiredDescriptionDefault
app_idYesThe app uuid returned by `apps_list`.
shop_domainNoOptional myshopify domain (e.g. "acme.myshopify.com"). When supplied, the store variables show that store's values instead of samples, empty where the store has none.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only cover safety (readOnly, non-destructive, closed-world), and the description adds real behavior beyond that: required scopes (emails.view, plus crm.merchants.view for real store values), the unknown-store fallback to samples, and the sample_source / store_found flags that distinguish real from placeholder data. These are exactly the traits an agent cannot derive from structured fields.

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 catalog description leads, followed by the shop_domain behavior and then auth requirements, so the most important facts come first. Sentences are dense but each carries distinct information. The parenthetical listing which variables stay placeholders is slightly sprawling but still earns its place.

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?

There is no output schema, so describing the returned entry shape (name, sample text, metadata, sample_source, store_found) is necessary and done. Permissions, parameter dependencies and fallback behavior are all covered. Nothing an agent needs to call this correctly is missing.

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 100%, so the baseline is 3 and the schema already documents all three parameters. The description still adds cross-parameter meaning the schema does not: which variables remain placeholders regardless of shop_domain (contact, event, custom field), that empty means the store has no value, and that app_id may be a slug when organization_id is supplied.

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 states a specific verb and resource: it returns the merge-tag variable catalog an email send can substitute, covering built-in tags plus CRM custom fields. That is much more specific than the name alone. It stops short of naming a competing sibling (e.g. managed_variables_list or custom_fields_list), so an agent must infer the boundary rather than being told it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear conditional: pass optional shop_domain to get a store's real sample values instead of generic ones, and it states app_id comes from apps_list. What it does not say is when to call this versus managed_variables_list or custom_fields_list, nor what a caller should do with the catalog afterwards. Usage is implied rather than routed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources