Skip to main content
Glama
Sign In

Meridian

by ai.the-meridian
OverviewDiscussions(2)Admin

Get Email

email_get
Read-only

Returns one email template's metadata and rates: email_id, name, status, subject, preview_text, open/click/conversion rates, and timestamps. Never includes design JSON or rendered HTML. Takes the app_id from apps_list and the email_id from emails_list / email_create. Recomputes rates from local send rows before returning so missed webhook deliveries do not leave stale numbers.

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>",
      "email_id": "<email_id>"
    },
    "name": "email_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
app_idYesThe app uuid returned by `apps_list`.
email_idYesThe email uuid returned by `emails_list` or `email_create`.
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.4/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses important behavior: the exact returned field set, the exclusion of design JSON and rendered HTML, and the fact that rates are recomputed from local send rows to avoid stale webhook-derived values.

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 front-loaded with the return payload, then constraints, then ID provenance and freshness behavior. It is dense and efficient, though the ID provenance slightly duplicates the schema.

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 the description must explain return values; it does so by enumerating the included fields and explicitly excluding design JSON and rendered HTML. It also covers the freshness behavior that an agent might otherwise misinterpret as plain stored data.

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 100%, so the schema already carries the parameter semantics. The description repeats the provenance of app_id and email_id but adds no additional meaning, and it does not clarify the optional organization_id beyond what the schema states.

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 description uses a specific verb and resource: it returns one email template's metadata and rates. It also distinguishes the result from heavier sibling-style reads by explicitly stating that design JSON and rendered HTML are never included.

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?

It gives useful prerequisite context by naming where app_id and email_id come from (apps_list, emails_list, email_create). It does not explicitly name when to use this instead of update/create alternatives, so it stops short of full when/when-not guidance.

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

All Meridian toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources