Read ONE support ticket by its number (as shown in list_support_tickets), including the full body/description. Read-only, scoped to Dock's support repo. Returns not-found for a number that isn't a support ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The ticket number from list_support_tickets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states it is read-only, scoped to Dock's support repo, returns the full body/description, and handles non-existence with a not-found response. This goes well beyond the bare minimum and gives the agent a clear understanding of behavior.
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, front-loaded with the main action and purpose. Every sentence adds value: the first defines what it does, the second clarifies scope and error behavior. No filler 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 simple single-read tool with one parameter and no output schema, the description is complete. It covers what the tool does, how the parameter is obtained, the return content (full body/description), the scope, and the not-found behavior. Nothing important is missing for an agent to use it correctly.
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 input schema already documents the single parameter 'number' with a description referencing list_support_tickets. The tool description adds minimal extra meaning ('as shown in list_support_tickets') which essentially duplicates the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.
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 clearly states the action ('Read ONE support ticket by its number'), the resource ('support ticket'), and scope ('scoped to Dock's support repo'). It distinguishes itself from sibling tools like list_support_tickets and create_support_ticket by focusing on a single read operation.
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 provides clear context for when to use this tool: you need a specific ticket number (as shown in list_support_tickets) and want the full body/description. However, it does not explicitly mention when not to use it or name alternative tools for other scenarios, so it lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, with detailed descriptions that prevent confusion. The main ambiguity arises from send_message vs. the referenced but missing message_teammate tool, and add_column vs. update_surface for schema changes, but these are mostly clarified by the descriptions.
The naming convention is predominantly verb_noun with underscores (e.g., create_workspace, list_rows, update_doc). Exceptions like 'search' and 'address_book' (no noun) and the two-word 'react_to_comment' are minor deviations in an otherwise consistent pattern.
With 68 tools, the surface is far too large for an MCP server, exceeding the 50+ threshold for extreme mismatch. This volume creates excessive selection overhead for agents and suggests the tool set could be consolidated or split into focused servers.
The server covers broad functionality across workspaces, docs, tables, HTML, comments, files, webhooks, and billing. However, notable gaps exist: the explicitly referenced message_teammate tool is missing (preventing agent-to-agent waking), and there is no create/upload file tool or create API key tool, which creates dead ends in workflows.