Loading ToolBench
Connect Parse public AI visibility data to MCP-capable clients.
Parse GL MCP has well-structured tool definitions with clear naming (verb_noun pattern) and reasonable descriptions (avg 150 chars). All 6 tools have input schemas with proper JSON Schema types. However, parameter descriptions are entirely absent, the schema objects lack 'description' fields for any input parameters. This is a critical gap: LLMs cannot infer what 'query', 'slug_or_id', 'limit', or 'types' mean without explicit text. Output schemas are not documented anywhere in the source. Error handling and recovery guidance are not visible. The two compatibility aliases (search, fetch) add confusion rather than clarity, they duplicate functionality without clear disambiguation. No tool annotations (readOnlyHint, etc.) despite all being read-only operations.
Compatibility alias that resolves fetch IDs like brand:stripe or prompt:best-crm into JSON-text results with human-readable text.
Fetch a concise public marketing brief for one brand, including Parse score, strengths, weak spots, top prompts, citation sources, related brands, and next research questions.
Fetch one public organic prompt by slug when the user wants to inspect the exact AI-search question behind a result.
Explain the public Parse index scale and freshness: tracked brands, organic prompts, and citation observations.
Find brands, organic AI prompts, citation sources, and market niches for marketer research. Use this first when the user names a brand, category, source, or AI visibility question.
Compatibility alias for parse_search. Use for clients that expect a generic search tool.
All input parameters lack descriptions. 'query', 'slug_or_id', 'limit', 'types', 'id', 'slug' have no text explaining what they mean, valid formats, or constraints. LLMs cannot infer parameter semantics from names alone.
Output schemas are not documented. Tools return complex objects (BrandProfile, PublicSearchResult, PublicPrompt) but the MCP tool definitions do not declare what fields or structure the LLM should expect. This forces LLMs to guess at response structure.
Duplicate tools 'search' and 'fetch' are compatibility aliases that confuse rather than clarify. They lack distinct descriptions explaining when to use each vs. the primary parse_* tools. This violates single-responsibility and forces LLM reasoning overhead.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
No tool annotations despite all tools being read-only. Adding readOnlyHint=true to each tool definition would signal to clients that these are safe, non-destructive operations and enable optimizations.
No error handling or recovery guidance visible in tool definitions. If a search returns no results, or a brand slug is invalid, the tool should guide the LLM on next steps (e.g., 'Try a broader query' or 'Use parse_search to find valid slugs').