Skip to main content
Glama
mailkite

MailKite

Official
by mailkite
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Hybrid

mailkite_agent

Send a message to an inbox agent and retrieve its reply. Target the default agent or specify a routeId or address to reach a specific agent. Requires an API key.

Instructions

Send a message to one of your inbox agents and get its reply. Defaults to the account's default agent; pass routeId or address to target a specific agent, or model to override the model. This is separate from inbound routing — it does not match or override routes. Requires an API key (mk_live_…).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromNoOptional sender address the agent sees as the originator. Defaults to the account's API caller address.
htmlNoOptional HTML body. `text` is still required — the agent reasons over the plain-text content.
textYesThe message for the agent — it reads this as the incoming email body and decides what to do.
modelNoOverride the model the agent runs on for this call (e.g. claude-sonnet-4-6).
addressNoTarget the agent whose route matches this address. Alternative to routeId.
routeIdNoTarget a specific agent by its route id (rte_…). Omit to use the account's default agent (its most recently created agent route).
subjectNoOptional subject line the agent sees on the message.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.20.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, it adds that the tool requires an API key (mk_live_…) and clarifies an important non-effect: it does not match or override routes. It does not describe the reply shape or potential side effects of sending a message to an agent, but the annotations already signal non-read-only and non-destructive behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it states the main purpose, then covers default/target/model selection, then the routing exclusion, then authentication. Every sentence earns its place and no filler is present.

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?

The essential behavior, auth requirement, parameter-target interaction, and boundary relative to routing are covered. Since there is no output schema, a brief description of the reply shape or error handling would make it complete, but the description still provides enough for an agent to use the tool correctly.

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?

The input schema already thoroughly describes all seven parameters, so the description mostly restates the targeting and model-override semantics rather than adding new meaning. It does not deepen the semantics of from, html, text, subject, address, or routeId beyond what is already in the schema.

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 opens with an unambiguous verb and resource: 'Send a message to one of your inbox agents and get its reply.' It also explicitly distinguishes the tool from inbound routing, saying it does not match or override routes, which differentiates it from siblings like mailkite_route and mailkite_create_route.

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 clear usage conditions: uses the default agent, or targets a specific agent via routeId or address, and optionally overrides the model. It also states a when-not boundary by clarifying it is separate from inbound routing, but it does not explicitly name a sibling alternative for regular outbound sending when the user does not want an agent.

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

Install Server

Other Tools