broken_linksAll broken affiliate links currently flagged by the LinkPulse scanner on this site. Status 4xx (dead) and 3xx (redirecting) are both included, grouped by post. Useful for audit-style questions and for piping into suggest_replacement.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals data grouping ('grouped by post') but does not disclose whether the tool is read-only, requires authentication, or has rate limits. For a tool listing broken links, this is insufficient.
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 sentences: first defines the tool's output precisely, second gives usage guidance. No wasted words, front-loaded with key information.
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?
Without an output schema, the description explains what is returned (broken links with status codes, grouped by post). It could specify the exact structure (e.g., list of posts with links) or mention pagination, but it's sufficient for a simple audit 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?
There are zero parameters, and schema coverage is 100%, so the description doesn't need to add parameter meaning. Baseline 4 applies per rules.
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 explicitly states the tool returns 'all broken affiliate links' with status codes 4xx and 3xx, grouped by post. It clearly distinguishes itself from siblings like 'suggest_replacement' and 'revenue_summary' by focusing on broken links.
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 says 'Useful for audit-style questions and for piping into suggest_replacement,' providing clear usage context. It doesn't explicitly state when NOT to use it, but the sibling tools imply alternatives, so it's nearly excellent.
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.
Each tool has a distinct purpose: at_risk_articles combines broken links with revenue loss, broken_links lists all broken links, revenue_summary gives revenue data, suggest_replacement finds alternatives, and top_articles shows top earners. There is no overlap.
All tool names follow a consistent snake_case pattern with descriptive terms like adjective_noun (at_risk_articles, broken_links) or verb_noun (suggest_replacement). No mixing of conventions.
5 tools is well-scoped for a server focused on affiliate link management and revenue optimization. Each tool serves a clear purpose without redundancy.
The set covers finding broken links, assessing revenue impact, and suggesting replacements, but lacks an 'apply_fix' tool to actually implement changes, which is mentioned as v1.1. Missing update/delete functionality for links.