Pin or unpin a Discord message in a channel or thread using its IDs. Requires the Pin Messages permission to keep important messages accessible.
Pin (default) or unpin a message. Needs the Pin Messages permission (Discord split it from Manage Messages).
| Name | Required | Description | Default |
|---|---|---|---|
| unpin | No | Set true to unpin | |
| channel_id | Yes | Channel ID (a thread ID also works) | |
| message_id | Yes | Message ID |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely useful auth context: the Pin Messages permission is required and was split from Manage Messages. It does not describe the return shape or idempotency, but the permission note is real added value beyond the structured fields.
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?
Two tightly written sentences with zero waste; the primary behavior and its default are front-loaded, and the permission caveat follows logically.
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 mutation tool with no output schema, the definition covers the key agent needs: what it does, the default direction, and the required permission. Return format and idempotency are unstated, but annotations already carry the safety profile, so the gap is minor.
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 all three parameters are already documented, including 'Set true to unpin'. The description reinforces that pinning is the default, which is a minor clarification rather than net-new meaning; baseline 3 applies when the schema does the heavy lifting.
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 clear verb+resource ('Pin ... a message') and covers both directions of the operation, distinguishing pin from unpin via the stated default. It does not name the read-side sibling (discord_list_pins), so sibling differentiation is left implicit.
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 by the verb: use it to pin or unpin a message. There is no explicit when-to-use vs alternatives or when-not guidance, and the adjacent read tool discord_list_pins is not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.