Loading ToolBench
MCP server providing SEO analysis tools integrated with SE Ranking API, Google APIs, and Firecrawl for domain intelligence, Google Search Console, GA4, Core Web Vitals, and web crawling capabilities
SE Ranking provides 6 tools with mixed quality. Tool naming follows verb_noun conventions (notify_url, get_notification_metadata, batch_notify, query_history, detect_trends, list_properties), which is good. Descriptions are present for all tools and generally 60-180 chars, meeting the 10-1024 char baseline. However, parameter descriptions are inconsistent, some parameters (url, action, urls) lack descriptions in the tool specifications shown, though they appear in docstrings. Input schemas are visible for all tools and include types and enums where appropriate. Output schemas are not explicitly documented in the source code provided, only function docstrings hint at return structures. Error handling is present in the implementation (e.g., 403/429/400 error classification in notify_url) but not reflected in tool definitions. The tools are well-focused (no 'and' clauses), and composition is sound, each tool does one thing. However, the lack of explicit output schema documentation and inconsistent parameter annotation in the tool registration (vs. implementation) are significant gaps for LLM reasoning.
Batch notify multiple URLs with quota awareness. Submits up to 200 URLs per day to the Indexing API with configurable delay between requests.
Analyze p75 timeseries metrics to detect Core Web Vitals trends. Compares average of last 4 weeks to average of first 4 weeks to classify direction as improving, stable, or degrading.
Get the latest notification metadata for a URL, including latest update and remove timestamps from the Indexing API.
Enumerate every GA4 account and property the credentials can see. Returns accounts with property IDs, display names, and timezones.
Publish a single URL notification to the Indexing API. Supports URL_UPDATED or URL_DELETED actions to notify Google of URL changes.
Query CrUX History API for weekly Core Web Vitals trends over time. Fetches up to 25 weekly data points and identifies improving, stable, or degrading trends per metric.
Output schemas not explicitly documented in tool definitions. LLMs cannot infer what fields to expect from each tool's response, blocking downstream tool chaining and field extraction.
Parameter descriptions are sparse in tool specifications. The 'url' param in notify_url and get_notification_metadata lacks description in the Input schema shown. Parameter descriptions are critical for LLM understanding, they cannot infer that 'url' means a full URL vs. origin.
Error handling guidance not exposed in tool definitions. The implementation contains rich error classification (403→permission denied, 429→quota exceeded, 400→invalid input), but tool specs do not document these error conditions or recovery paths. LLMs cannot plan for failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 74 | 2026-07-28+ | v2 |
API credentials (Google API key in query_history, service account in Indexing API) are managed via environment/oauth, which is correct. However, the tool spec for query_history explicitly lists 'api_key' as a parameter, this should be injected server-side, not passed by the caller. Secrets in parameters risk leaking into logs and prompt history.
list_properties has no parameters (empty input schema), which is correct for a discovery tool, but the description does not explain what the output contains (account/property structure, timezone info, etc.). LLMs cannot plan downstream tool calls without knowing what fields are returned.
detect_trends expects a 'metrics' parameter (object with p75_values timeseries), but the description 'Dictionary of metrics with p75_values timeseries' is vague. LLMs cannot infer the exact structure: is it {metric_name: [p75_values]}? {metric_name: {p75_values: [...]}}? A schema example or explicit format is needed.