get_site_mapGet the latest crawl snapshot for a target. Returns page inventory stats, SEO issues, broken pages/assets, response times, and a diff against the previous crawl. Optionally include page-level details.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | The target ID | |
| pageLimit | No | Max pages to return when includePages is true | |
| pageStatus | No | Filter pages by status | |
| includePages | No | Include individual page data (can be large). Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add behavioral context by saying 'latest crawl snapshot' and 'diff against previous crawl', implying a read-only, comparative action. However, it does not explicitly state read-only safety, rate limits, or potential data-size implications, which are not covered elsewhere.
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 two sentences, front-loaded with the main purpose and then listing key outputs. There is no fluff, and the structure makes it easy for an agent to grasp the tool's function quickly.
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?
There is no output schema, so the description must convey return value composition. It lists categories of data but lacks structural details, pagination behavior, and the interplay between includePages, pageLimit, and pageStatus. Given the moderate complexity, the description is adequate but incomplete.
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 the baseline is 3. The description adds little beyond the schema, only indirectly echoing includePages via 'page-level details' and hinting at pageStatus via 'broken pages/assets, response times'. It does not explain parameter interdependencies, so it stays at the baseline.
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 'Get' and specific resource 'latest crawl snapshot for a target', then enumerates distinct outputs (page inventory stats, SEO issues, broken pages/assets, response times, diff against previous crawl). This distinguishes it from sibling tools like get_target or get_finding.
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 usage for retrieving crawl snapshot data but does not explicitly state when to use it versus alternatives, nor provide any when-not or exclusion guidance. Sibling tools like analyze_target might be alternatives, but no comparison is made.
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.
Most tools are clearly separated by resource (targets, runs, findings, incidents, etc.) and action. A few close pairs like active_runs/list_runs and mute_finding/create_muting_rule could confuse, but descriptions clarify the distinctions.
The majority of tools follow verb_noun naming (create_target, get_target, delete_journey). A few outliers use noun phrases (active_runs, daily_trends, system_health, team_stats) which slightly breaks the pattern, but overall the convention is predictable.
74 tools is extreme for any MCP server. Even for a comprehensive monitoring platform, this overwhelms agents with too many granular operations (e.g., enable_all_tests vs disable_all_tests vs update_test, or import_targets duplicating create_target). A more consolidated set would be appropriate.
The tool surface is remarkably complete for the monitoring domain: full CRUD for targets, journeys, rules, reports, secrets, and fragments; plus run triggering, incident management, findings handling, SEO tracking, guest scans, and admin tools. Only maintenance windows lack an update operation, which is minor.