Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

mailpool_domains

Mailpool domains: read them, audit their deliverability setup, look up a new name.

Ops:

  • list — the workspace's domains (type google/outlook/shared/private, status, expiry, redirect). limit (1-100) / offset paginate.

  • get — one domain (domain_id).

  • dns — the DNS records Mailpool holds for a domain (domain_id), as {type, key, value, priority}; key is the host label, null = apex.

  • audit — findings on SPF, DKIM, DMARC, MX, CNAME conflicts and custom tracking domain, worst first, for one domain (domain_id) or a page of domains (at most 20 per call: total and next_offset say what is left). Read from Mailpool's stored configuration, not a live DNS lookup. Fix what it finds with mailpool_domain_fix.

  • availability — can domain be registered, and at what price. Nothing is bought (registration is not served by this connector).

  • suggestions — available names close to domain, with price.

  • google_workspace_check / microsoft_365_check — is domain already used by a Google Workspace / Microsoft 365 account (enabled per Mailpool workspace, otherwise refused).

  • owners — saved registrant contacts (company and country only).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "mailpool_domains"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNowhat to do (see above).list
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
limitNopage size, 1-100 (at most 20 for `audit`).
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
domainNodomain name, for availability/suggestions/checks.
offsetNoitems to skip.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
domain_idNoMailpool domain id (from `op="list"`).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does meaningful work: audit reads Mailpool's stored configuration rather than doing a live DNS lookup, audit results are ordered worst first and capped at 20 per call with `total`/`next_offset`, availability and suggestions buy nothing, and the two provider checks can be refused entirely. What it does not state is whether any op mutates state or what permissions/quotas apply, though the read-only framing is implied throughout.

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?

One scoping sentence followed by a flat bulleted op list is well front-loaded and easy to scan; every bullet maps to an enum value. A few entries are terser than ideal ('with price', 'company and country only') but nothing is truly wasteful.

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?

For a nine-op multiplexer with no output schema and no annotations, this is complete enough to call correctly: each op's required identifier, pagination rules, refusal condition, and key return fields are stated. The unannotated plumbing parameters are documented in the schema itself, so nothing essential 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 already 100%, so the description's added value is the routing map: `domain_id` for get/dns/audit, `domain` for availability/suggestions/checks, `limit`/`offset` only for list and audit. It also documents output field shapes for dns (`type, key, value, priority`, null key = apex) that the schema does not. The 10 plumbing parameters (_org, _group, _run_id, _project, _instance) are left entirely to their schema text.

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 line names the resource and the three families of work (read, audit deliverability, look up a new name), then enumerates all nine ops with the exact action each performs. It explicitly distinguishes itself from the sibling mailpool_domain_fix by pointing there for fixes, and from registration by noting that buying is not served by this connector.

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?

Each op carries its own selection context: audit is for a single domain or a page of at most 20, availability/suggestions take `domain` not `domain_id`, and the Google/Microsoft checks are 'enabled per Mailpool workspace, otherwise refused'. The remaining gap is that it never says when to prefer this over nearby siblings such as mailpool_account or mailpool_mailboxes for overlapping domain questions.

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

All Tulina toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources