Aftersearch Verify Serp
aftersearch_verify_serpVerify pasted SERP/AI text or one caller-provided public URL; returns confirm, contradict or missing with sources.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| serp_text_or_url | Yes |
aftersearch_verify_serpVerify pasted SERP/AI text or one caller-provided public URL; returns confirm, contradict or missing with sources.
| Name | Required | Description | Default |
|---|---|---|---|
| serp_text_or_url | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive; the description adds that the tool produces a classification ('confirm, contradict or missing') and attaches sources, plus that URLs must be public. This extra behavioral/return context is useful and doesn't conflict with the annotations.
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 compact sentence that front-loads the verb, scopes the input, and states the output. No redundant phrases or restating of the tool name.
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 one-parameter tool with no output schema and safety hints covered by annotations, the description covers the essential invocation details: what to pass and what to expect back. It is slightly thin on what 'sources' means or how contradictory evidence is presented, but that does not block correct usage.
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?
With schema coverage at 0%, the description does the semantic work for the single parameter: it specifies that serp_text_or_url can hold pasted SERP/AI text or exactly one caller-provided public URL. This clarifies the accepted formats beyond the bare parameter name and length constraints.
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 ('Verify') and identifies the exact resource: pasted SERP/AI text or a caller-provided public URL. It also defines the return semantics (confirm/contradict/missing with sources), which distinguishes it from sibling aftersearch actions like accept/quote/resolve.
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?
It clearly tells an agent when to invoke it: whenever there is pasted SERP/AI text or a single public URL that needs verification. It does not, however, list alternative tools or exclusion criteria, so it stops at clear context without when-not 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.