List site lists
list_site_listsSite lists (placement black/white lists).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| search | No | Filter by name | |
| per_page | No | Rows per page (default 50, max 100) |
list_site_listsSite lists (placement black/white lists).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| search | No | Filter by name | |
| per_page | No | Rows per page (default 50, max 100) |
Changes observed during successful MCP inspections.
No schema history has been recorded yet.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered externally. The description adds only the semantic gloss on what a site list is and says nothing about return shape, pagination behavior, or how the three query parameters combine.
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?
There is zero wasted wording, but the single parenthetical fragment is under-specified rather than concise; it reads as a glossary entry, not a tool description with a front-loaded action.
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?
This is a simple three-parameter list tool, but with no output schema the description should at least indicate what a returned list contains or that results are paginated. As written, an agent knows the concept but not what calling it yields.
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% and all three parameters (page, search, per_page) carry their own defaults and limits. The description adds nothing about them, so the baseline 3 applies – the schema does all the work.
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 fragment names the resource and glosses it as 'placement black/white lists', which gives real domain meaning beyond the title. However, it lacks an explicit verb and does not distinguish it from the sibling get_site_list (single fetch) or list_whitepages, both of which an agent could confuse it with.
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?
There is no when-to-use guidance, no mention of pagination expectations, and no pointer to get_site_list for retrieving a single list. The agent must infer the list-vs-get distinction purely from the name.
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.