Loading ToolBench
Tracks average product citations to evaluate search performance index for generative engine visibility
This MCP server has a single tool with critical definition gaps. The tool exists and has a basic schema, but lacks essential LLM-facing guidance. The description is extremely terse (73 characters), providing minimal context about when or why to use the tool. The input schema is present but severely underdeveloped: the 'llm_mentions' parameter is typed as a bare 'object' with no internal field specifications, no constraints, and no guidance on what keys are valid or what value ranges are acceptable. The output schema is not documented anywhere in the code. Error handling is completely absent, the implementation has no validation, no try/catch, and would crash on invalid input (e.g., non-numeric values in the dict). The tool lacks actionable descriptions for its parameter and returns, making it impossible for an LLM to use this tool effectively without trial-and-error. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The implementation is a plain Python class with no MCP server registration visible in the provided code, only a client SDK and example usage are shown, raising doubt about whether this is actually integrated into an MCP server at all.
Tracks average product citations to evaluate search performance index
Tool description is too terse (73 chars). Lacks WHAT the tool does, WHEN to use it, and prerequisites. 'Tracks average product citations to evaluate search performance index' does not explain the actual function: the tool calculates a visibility percentage and brand strength category from LLM mention counts. An LLM cannot determine whether to use this tool based on this vague description.
Input schema is incomplete. The 'llm_mentions' parameter is typed as a bare 'object' with no internal field schema, no description of valid keys, and no value constraints. The description says 'Dictionary mapping LLM names to citation counts' but does not specify: (1) what LLM names are valid (enum?), (2) what range citation counts must be in (integer >= 0?), (3) whether any keys are required. This forces LLMs to guess at valid inputs and causes failures.
No output schema documented. The code returns a dict with 'visibility_index_pct' (float) and 'brand_strength' (enum-like string), but the MCP server definition does not declare this output structure. LLMs cannot plan downstream operations or extract fields reliably without a documented schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 28 | 2026-07-28+ | v2 |
No error handling or validation. The implementation will crash if 'llm_mentions' is not a dict, if values are non-numeric, or if the dict is empty. There are no try/catch blocks, no validation messages, and no guidance for an LLM on how to recover from invalid input. Production tools must return actionable error messages, not stack traces.
No tool annotations. The tool modifies nothing and reads data only, making it a safe read-only operation, but there is no readOnlyHint annotation to signal this to the MCP client. Tool annotations help agents reason about side effects and retry safety.
No visible MCP server registration. The provided code shows only a Python client SDK (GenerativeEngineVisibilityTrackerClient) and example usage, with no MCP server implementation visible. It is unclear whether this repo actually exposes an MCP server, or if it is only a library. Without evidence of MCP server scaffolding (transport initialization, tool registration, message handlers), the entire submission is questionable.