MCP server providing access to Rootdata API for cryptocurrency and blockchain project intelligence, including project data, funding information, investor details, ecosystem analysis, and trend tracking
Rootdata MCP has 17 tools with complete JSON Schema definitions and descriptions present for all tools. However, quality is inconsistent. Tool names lack clear verb-noun structure (e.g., 'analyzeComprehensive' vs 'analyze_project', 'investigateEntity' vs 'investigate_entity'). Descriptions are present but generic, most are 50-120 chars, below the 194-char baseline for production tools. Parameter descriptions exist but lack actionable constraints: no ranges for numeric params (page, pageSize, days), no format guidance for timestamps, no enum validation hints in descriptions. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance or actionable error messages visible in code. Type guards exist but validation is loose. Overall, definitions are structurally sound but lack the depth and precision needed for reliable LLM reasoning.
Comprehensive analysis combining multiple RootData endpoints for a holistic view
Compare multiple entities across various metrics
Get funding rounds with filtering and pagination options
Get hot projects for a specified number of days
Get a list of investors with pagination support
Get job changes including recent joiners and resignations
Tool names use camelCase instead of snake_case verb_noun convention. Names like 'analyzeComprehensive', 'investigateEntity', 'trackTrends' lack clear action verbs and violate the 90% baseline of A+ tools starting with explicit verbs (get_, search_, list_, create_). LLMs struggle to parse intent from ambiguous names.
Output schemas are not documented. No tool description specifies what fields the response contains, their types, or structure. LLMs cannot plan downstream tool calls or extract required data (e.g., does getProject return investor_ids for chaining to getInvestors?). Violates 100% baseline for A+ tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Get detailed information about a specific organization
Get detailed information about a specific person
Get detailed information about a specific project
Get projects filtered by ecosystem IDs
Get projects filtered by tag IDs
Get hot projects from X (Twitter) with various ranking options
Get popular figures from X (Twitter) ranked by heat or influence
Deep investigation of a specific entity with configurable scope
Search for projects in the Rootdata database
Get synchronized updates within a time range
Track trends across various categories with filtering options
Numeric parameters lack constraints. 'page' and 'pageSize' have no min/max bounds; 'days' in getHotProjects has no range guidance. LLMs can pass absurd values (page=999999, pageSize=1000000, days=36500) that break APIs or cause timeouts. Descriptions should state '1 - 100' or similar.
Tool descriptions are generic and under 100 chars on average. Baseline is 194 chars. Descriptions like 'Get detailed information about a specific project' lack WHEN to use, dependencies, or actionable context. LLMs cannot distinguish between similar tools (getProject vs searchProjects) without richer descriptions.
No error handling guidance in code. Type guards validate input but no tool returns actionable error messages. If an API call fails, LLMs receive raw errors with no recovery path. Missing pattern: 'User not found. Try search_users() first.' or 'Invalid status: must be one of: open, in_progress, resolved.'