mark_duplicate

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the marking action and its educational purpose, but does not explain side effects (e.g., whether the thread is hidden, locked, or if reversing is needed), permissions, or reversibility. This is a significant gap for a state-changing tool.

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 highly concise: a single purpose sentence, a usage sentence, and a clear Args block. It is front-loaded with the core action and uses no unnecessary words or redundancy.

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 tool with an output schema, the description covers the essential aspects: what the tool does, when to use it, and the meaning of each parameter. The only missing element is deeper behavioral context (already penalized in transparency), but overall the agent can correctly select and invoke the 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 0%, but the description fully compensates by explicitly defining both parameters: thread_id as 'the global ID of the duplicate thread' and original_thread_id as 'the global ID of the original thread it duplicates.' It also tells the agent where to obtain these IDs (list_threads or search_threads), adding actionable meaning.

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 uses a specific verb+resource: 'Mark a thread as a duplicate of another thread.' It clearly identifies the action and object, and the usage note about pointing students to the original distinguishes it from other thread-modification tools like delete_thread or lock_thread.

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 explicitly states when to use the tool: 'Use this when a question has already been answered elsewhere to point students to the original.' This gives clear context, though it does not mention when not to use it or name alternative tools (e.g., unmark_duplicate).

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