Read direct messages

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond those annotations: it reveals the privacy model ('anyone mentioned in one can see it') and the ordering behavior ('newest first'). This helps an agent understand side effects and visibility semantics.

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 first sentence is front-loaded with the core behavior, and the second explains a key Mastodon-specific nuance. The third sentence about existing MCP servers is not directly actionable for invoking the tool, but it is brief and does not significantly bloat the description. Overall it is tight and well ordered.

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 reasonably summarizes the return shape ('participants and last message') but leaves out response envelope, pagination behavior, and exact field structure. The two parameters are fully described in the schema, so the main gap is response detail. This is adequate but not fully complete.

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 'limit' and 'account' are already well documented by the input schema. The tool description adds no additional parameter-level explanation, which is acceptable given the schema's completeness. Baseline 3 is appropriate here.

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 names a specific resource ('Direct conversations') and states exactly what is returned: 'newest first, each with its participants and last message.' It also clarifies that Mastodon direct messages are statuses with visibility 'direct', which helps distinguish this from standard timeline tools. This is a clear, actionable purpose statement.

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 gives useful context about how Mastodon models direct messages, implying when this tool is relevant. However, it does not explicitly say when to prefer this over alternatives like get_home_timeline or mute_conversation, and it offers no exclusionary guidance. The usage intent is clear but largely inferred.

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