dp_get_related_toolsGiven a directory tool slug, return other tools in the SAME category ranked by ADO score — a shortlist of peers/alternatives within the directory. Excludes the input tool.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug to find peers for, e.g. 'signal'. | |
| limit | No | Max related tools (default 5). |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful behavioral details—ranking by ADO score and excluding the input—but does not describe return format, pagination, or default limit behavior beyond the 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?
The description is a single, focused sentence that front-loads the primary purpose and adds key constraints (same category, ADO score, excludes input) without any wasted words.
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?
Given the tool's simplicity, two well-documented parameters, and a read-only annotation, the description covers the essential context. It does not detail the output shape, but for a simple list-returning utility, this is sufficient.
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 slug and limit are already documented. The description clarifies that the slug refers to a directory tool and that results are same-category peers, but it does not add significant meaning beyond the schema's parameter descriptions.
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 verb (return), the resource (other tools in the same category), and the ranking criterion (ADO score). It also explicitly notes that the input tool is excluded, which distinguishes it from sibling tools like dp_find_alternatives and dp_compare_tools.
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 implies when to use the tool: when you need a shortlist of tools in the same category as a given directory tool. It does not explicitly list exclusions or alternative tools, but the phrase 'peers/alternatives within the directory' provides clear context for its purpose relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.