Give AI agents own email inbox, SMS numbers, and workspace accounts to receive and send messages.
Scored across 5 tools
messages.list, messages.read, and messages.send are clearly distinct actions on the same resource. status and team.list both expose agent-account information and could be slightly confused, but their stated scopes differ enough for an agent to choose correctly.
Four tools use a readable resource.action dot convention (messages.list/read/send, team.list). status is a bare singleton name and breaks the pattern mildly, but overall naming remains predictable.
Five tools is well-scoped for a messaging server aimed at AI agents: list, read, send, current identity, and team directory. Each tool has a clear role without bloat.
The core messaging lifecycle is covered: receive/list, read with attachments, send/reply/forward, account status, and team lookup. Minor gaps like search, thread listing, archive/delete, or explicit SMS-specific handling are workaroundable for core agent workflows.
List the messages the agent account received, newest first. A refused message did not wake the agent, and its reason says why; a received one's admission says whether its sender is on the team, on the channel's list, or anyone else; an imported one came from a mailbox the agent used before.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Keep the messages from this address | |
| agent | No | The id of the agent account to act as, from status. Leave it out when these tools act as one agent account. | |
| limit | No | How many to list, from 1 to 25 | |
| before | No | List the messages older than this one; pass the last id listed to page back | |
| channel | No | Keep the messages that came on this channel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile needs no restating. The description adds genuinely useful semantics the annotations cannot cover — that refused messages did not wake the agent, that a 'reason' explains refusal, that 'admission' signals the sender's relationship, and that imported messages came from a prior mailbox — but it does so only as a dense aside and says nothing about result shape or volume.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action and ordering lead the sentence, and the remaining clauses are packed but each carries real information about message states. The second sentence is long and semicolon-chained, which slightly hurts scanability, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values, and it partly does so by defining the three message states and the meaning of their `reason` and `admission` fields. What remains unstated — the overall result envelope and pagination cursor behavior outside the schema — is minor for a five-optional-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so `from`, `agent`, `limit`, `before`, and `channel` are all documented in the schema, including paging via the last id. The description adds only the ordering guarantee ("newest first"), which the schema does not state, but nothing about the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("List the messages the agent account received") plus ordering ("newest first"), which is enough to distinguish it from messages.read or messages.send by implication. It stops short of naming those siblings explicitly, so routing is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance: nothing says to prefer this over messages.read for fetching a single message, nor any prerequisites or exclusions. Usage must be inferred entirely from the name and the word "list."
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a message the agent account received or sent, with its text and the files it came with. A sent message that failed has an error saying why. Each file has a download link that works for 15 minutes with no sign-in; read the message again for a fresh one.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The message's id, from messages.list or an event | |
| agent | No | The id of the agent account to act as, from status. Leave it out when these tools act as one agent account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, non-destructive, non-openWorld, so the safety profile is covered. The description adds real context beyond that: failed sent messages carry an explanatory error, and file links expire after 15 minutes and need no sign-in, requiring a re-read. It does not mention any access prerequisites, but the behavioral surface is otherwise well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what is returned, then the failure case, then the link expiry caveat. No filler and nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with no output schema, the description covers what is returned (text, files), the error case for failed sends, and the operationally important 15-minute link expiry with the remedy. An agent has everything needed to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the id and agent parameters are already documented, including where to get the id and when to omit agent. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Read a message") plus the scope (received or sent by the agent account) and what comes back (text and attached files). That distinguishes it implicitly from messages.list, since this is a single-message retrieval, but the sibling is never named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: read one message by id from messages.list or an event. It does give a useful operational cue — read the message again to get a fresh download link — but there is no explicit when-to-use vs when-not guidance relative to messages.list or messages.send.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message from the agent account. To answer one, give its id in replyTo: the answer goes back the way it came. To start a conversation, give a channel and recipients in to. To pass a message on, give its id in forward and recipients in to; its files go along. Files to send go in attachments.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | Who gets a copy, addressed as in to; only email copies. To answer everyone, copy the others the message named in to and cc | |
| to | No | Who to send to: email takes email addresses; sms takes a phone number that texted the agent first, or another agent's number in the workspace; telegram takes the id of someone who wrote to the agent's bot first, or a bot's @username; url takes the id of one agent from team.list | |
| text | Yes | The message, in plain text | |
| agent | No | The id of the agent account to act as, from status. Leave it out when these tools act as one agent account. | |
| channel | No | The channel to start a conversation on; a forward goes on its message's unless given | |
| forward | No | The id of a message to forward to the recipients in to: its sender, date, subject and text go below yours | |
| replyTo | No | The id of the message to answer; the answer goes to its sender, or to everyone the agent's own message went to. Answer another agent only if its message asks for an answer. | |
| subject | No | The subject, on a channel that has one; a new conversation there needs one, and an answer keeps its message's | |
| attachments | No | Files to send: a file from a message the agent received or sent, by the id in its attachments, or a small text file by name, type and text. A file from this conversation cannot be sent; have it mailed to the agent, then send it on by its id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and openWorldHint, and the description reinforces the external reach of the tool by naming email, sms, telegram and url delivery, plus the rule that a forward carries the original files along. It also discloses a real limitation not visible in annotations: a file from the same conversation cannot be attached and must first be mailed to the agent. It never states that a send cannot be recalled, leaving that inference to the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the purpose and then ordered by intent, with essentially no filler. The compressed phrasing ('the answer goes back the way it came') costs a little immediate clarity but keeps the block compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter tool whose parameters are invoked in mutually exclusive modes, the description covers the correctness-critical combinations and cross-references status and team.list inside the schema. It never says what a successful send returns, which matters for a tool that likely yields a message id needed for later reply or forward, and no output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already carries a rich description covering channels, recipients, forwarding semantics and attachment limits, so the schema does most of the work. The description restates the three mode combinations at a high level but adds no format, limit or constraint detail beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource, 'Send a message from the agent account', then enumerates three operating modes: reply via replyTo, new conversation via channel plus to, forward via forward plus to. That makes the tool's scope unambiguous against read-only siblings like messages.list and messages.read, but no sibling is named, so it stops short of explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is essentially a mode-selection guide: it states the exact parameter combination for answering, for starting a conversation and for forwarding, each tied to the intent that triggers it. An agent can pick the correct invocation shape without consulting anything else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the agent account these tools act as, or your workspace's agent accounts when they act as you, with the addresses people reach each one at. An agent account's signedInBy is the address of the member who signed this client in, usually the person you work with.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a safe, read-only, non-destructive, closed-world operation. The description adds useful behavioral context about what is returned: account addresses and the meaning of signedInBy, including that it identifies the member who signed the client in.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the main behavior before explaining signedInBy. It is appropriately sized for a no-parameter status tool, though the first sentence is slightly dense and could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and read-only annotations, the description carries most of the burden for explaining return semantics. It does so partially by naming the accounts, addresses, and signedInBy meaning, but it does not fully describe the shape of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics burden. The schema itself has 100% description coverage and no inputs to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it shows the agent account the tools act as, or the workspace's agent accounts, along with their reachable addresses. It is clear enough to distinguish this identity/account-inspection tool from the message and team siblings, though the phrasing is somewhat convoluted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by describing two contexts: showing the agent account these tools act as, or showing workspace agent accounts when they act as the user. However, it does not explicitly say when to call this versus alternatives such as team.list, nor does it give when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the workspace's agent accounts and members with their ids and addresses, and whether a client listens to each agent for its messages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine value beyond that by specifying what the response contains — member ids, addresses, and per-agent client listener status — which is not derivable from the annotations or the empty schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, though the clause 'whether a client listens to each agent for its messages' is slightly convoluted and could be phrased more directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the burden of describing return content and does so adequately (ids, addresses, listener status). It does not mention ordering, page size, or whether results are complete in one call, which is a minor gap for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema baseline of 4 applies. The description correctly implies no filtering or arguments are needed, returning the whole team.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('workspace's agent accounts and members') and enumerates the fields returned (ids, addresses, listener status). It is distinguishable from messages.* siblings by resource, though it never explicitly contrasts itself with the vague sibling 'status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: call this to see the team. There is no statement of when to prefer it over 'status' or the messages tools, and no prerequisites or exclusions are given. For a zero-parameter read tool the implied usage is largely sufficient, but no explicit routing guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
messages.list2 fields changedInput schema / properties / agent / formatRemoved value: -"uuid"Input schema / properties / agent / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"messages.read2 fields changedInput schema / properties / agent / formatRemoved value: -"uuid"Input schema / properties / agent / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"messages.send2 fields changedInput schema / properties / agent / formatRemoved value: -"uuid"Input schema / properties / agent / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"messages.listmessages.readmessages.sendstatusteam.list
Add one secure layer between your agents and this server.