how_to_useReturns a plain-English usage guide for this server — example requests, what it asks the user for, and the available tools. Call this if the user asks how to use Abby SEO, or to orient yourself before starting. (Same content as the 'getting_started' prompt, exposed as a tool for clients that don't surface MCP prompts.) Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it takes no arguments and returns a guide, and notes that content is same as the 'getting_started' prompt. No contradictions.
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, front-loaded with the main purpose, no wasted words. Perfectly concise.
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 tool with no parameters, no output schema, and a straightforward return of a usage guide, the description provides all necessary context. Complete and self-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?
No parameters; baseline is 4. Description reaffirms 'takes no arguments', which is helpful for confirmation.
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?
Clearly states it returns a plain-English usage guide for the server, including example requests, what it asks the user, and available tools. Distinguishes itself from sibling tools by being a meta-tool for orientation.
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?
Explicitly says 'Call this if the user asks how to use Abby SEO, or to orient yourself before starting.' Provides clear when-to-use and context for the agent.
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 clearly distinct purpose: starting scans, polling status, retrieving results, looking up old scans, checking purchase status, purchasing, getting remediation plans, and server documentation. No ambiguity between tools.
Seven tools follow a consistent verb_noun pattern (e.g., get_scan_results, purchase_report). The outlier 'how_to_use' deviates slightly from the pattern. Overall naming is coherent and readable.
Eight tools cover the full SEO scan workflow without being excessive. Each tool serves a necessary step, from submission to remediation, so the count is well-scoped for the server's purpose.
The tool set covers the core workflow: scan submission, status polling, results retrieval, purchase, purchase status, and remediation plan retrieval. A minor gap is the lack of a tool for user account management or scan history beyond email lookup, but these are not essential for the primary use case.