Google PageSpeed Insights report for a URL: Lighthouse performance/accessibility/SEO scores and Core Web Vitals (LCP, CLS, INP, FCP, TTFB), with lab and field (CrUX) data. Defaults to mobile; pass strategy=desktop for the desktop profile. Subject to a per-user daily cap (50/day) and a service-wide daily cap; successful responses are cached for 24h.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| strategy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several behavioral traits beyond the annotations: per-user and service-wide daily caps (50/day), successful responses cached for 24h, and the default strategy. These details are not present in the annotations and provide critical operational context.
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 long and every clause adds value: purpose, metrics, strategy guidance, and rate-limit/caching constraints. There is no repetition or filler, making it highly efficient.
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?
Although there is no output schema, the description enumerates the exact return data (Lighthouse scores, Core Web Vitals, lab/field data), making the output expectations clear. Combined with parameter guidance and rate-limit information, this is fully complete for a read-only, 2-parameter 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?
The schema is minimal (url string, strategy enum) with 0% description coverage, but the description adds meaning to the strategy parameter by explaining its default and how to switch between mobile and desktop. The url parameter is self-explanatory and doesn't require further elaboration.
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 it produces a Google PageSpeed Insights report for a URL and enumerates the exact metrics returned (Lighthouse scores, Core Web Vitals). This distinguishes it from sibling tools like get_page_seo and get_site_health, making its purpose unambiguous.
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 provides clear context for when to use the tool (for performance/accessibility/SEO metrics) and includes specific parameter guidance ('Defaults to mobile; pass strategy=desktop'). However, it does not explicitly name alternatives or state when not to use it, so it lacks the explicit 'when/when-not' distinction.
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.
The tool set is largely well-disambiguated with clear prefixes (get_, outreach_, zeekeo_) and detailed descriptions for each tool. Some tools like get_site_explorer and get_site_health could be confused at a glance, but their descriptions clearly separate their purposes. Overall, the naming and descriptions prevent meaningful ambiguity.
All tools follow a consistent get_ prefix for data retrieval, with sub-prefixes like get_gsc_, get_page_, and outreach_/zeekeo_ for distinct workflows. There is no mixing of naming conventions (e.g., camelCase) or inconsistent verb usage. The naming pattern is uniform and predictable.
With 63 tools, this server vastly exceeds the typical 3-15 tool scope, categorizing as an extreme overflow. Even for a comprehensive SEO and outreach suite, the sheer number is overwhelming and likely includes redundant or overlapping functionality. This would be confusing for agents and users alike.
The tool set covers a wide range of SEO, backlink analysis, Google Search Console data, and outreach workflows, appearing nearly complete for its stated purpose. However, several tools are marked as 'v1 stub' (e.g., get_internal_links, get_schema_markup), indicating incomplete functionality. Despite these gaps, the overall coverage is extensive and well-rounded.
