Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

mailpool_spam_checks

Mailpool spam checks: send a test email from a mailbox and score it.

Ops:

  • run — check mailbox_id. Free. With wait=True (default) waits up to ~20 s for the result (usually a few seconds); a check still pending after that is returned as is, to read later with op="get". Some mailbox types are refused by Mailpool (404).

  • get — one check (spam_check_id) with its detailed results.

  • list — past checks with score and per-check status.

  • delete — remove one check (spam_check_id) from the history.

Results: score (0-100) and checks — SPF, DKIM, DMARK (DMARC), domainAge, reverseDNS, ipBlackList, domainBlackList, spamAssassin, shortUrls, brokenLinks — each passed / warning / error.

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_spam_checks"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNorun, get, list or delete.list
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
waitNoop="run" — wait for the result.
limitNopage size, 1-100 (op="list").
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
offsetNoitems to skip (op="list").
_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')`.
mailbox_idNomailbox to check (op="run").
spam_check_idNocheck id (op="get"/"delete").

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.3/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 reasonably well: it discloses that `run` is free, that `wait=True` blocks ~20 s and may return a `pending` check, and that some mailbox types are refused with a 404. It does not say whether deleting a check is irreversible or whether the test email is actually delivered (reputation side effects) — meaningful gaps for a mutation-bearing tool.

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?

Front-loaded one-line purpose followed by a scannable per-op bullet list; nearly every clause carries information. The results enumeration is long but earns its place given there is no output schema. Minor typo ("DMARK (DMARC)") slightly undercuts polish.

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?

For an 11-parameter, no-output-schema tool this covers the operation matrix, blocking semantics, failure mode (404), and return fields well. Missing pieces are the origin of `mailbox_id`, list pagination behavior, and whether delete is permanent.

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, but the description adds real meaning: which identifier belongs to which op, that `wait` blocks ~20 s before returning a possibly-pending result, and the shape of the return (`score` 0-100 plus named `checks`). It says nothing about `limit`/`offset` pagination for `list` or the `_org`/`_project`/`_run_id` context parameters.

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?

States a specific verb+resource ("spam checks: send a test email from a mailbox and score it") and then enumerates the four operations (run/get/list/delete), so an agent can distinguish creating a check from reading history or deleting an entry without opening the schema.

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 is given a condition: `run` takes `mailbox_id` and is free, `get` takes `spam_check_id`, `list` shows past checks, `delete` removes from history. It also says a still-pending check should be read later with op="get". It does not point to sibling tools (e.g. `mailpool_mailboxes` for obtaining `mailbox_id`), so there is no explicit alternatives routing.

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