Loading ToolBench
MCP Server to explore and query the MathModDB knowledge graph using semantic search and SPARQL.
MathModDB MCP demonstrates above-average quality with well-documented tools, clear descriptions, and thoughtful design for schema-guided querying. All three tools have detailed descriptions (150-300+ chars) that explain WHAT they do, WHEN to use them, and HOW they fit into a staged workflow. Parameter descriptions are present and actionable. However, critical gaps exist: (1) No explicit input JSON Schema definitions visible in the source code, parameter types are inferred from annotations but not formally declared; (2) No output schemas documented, tools return strings (TOON-encoded or SPARQL results) but the structure of those results is not machine-parseable from the tool definition; (3) Missing error handling patterns, no recovery guidance or categorization of failures; (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear safety profiles (all tools are read-only). The workflow design is excellent (Explore_Ontology → SPARQL_Query → Batch_SPARQL_Query progression is clear), but the machine-readable metadata needed for robust agent planning is incomplete.
Execute multiple named SPARQL queries against the MathModDB knowledge graph. Use this tool when several related queries are needed in one request. Each dictionary key is preserved in the response as the corresponding result key. Important: Try to use FILTER statements sparingly to avoid rate limiting. Do not only rely on SPARQL schema discovery, use "explore_ontology" - It is faster! Rules: 1. Prefixes are preconfigured; do not declare PREFIX blocks. 2. Always include `LIMIT` (recommended <= 50, hard max 100) per query. 3. Query dictionary keys become result keys in the response.
STAGE 1 (REQUIRED): discover MathModDB Wikibase schema elements for query planning. Use this before `sparql_query`. It maps natural language to the IDs and properties you need in SPARQL. MathModDB is queried as a Wikibase graph: - Entities/classes use `wd:` IDs (example: `wd:Q6672081`) - Direct properties use `wdt:` IDs (example: `wdt:P31`) - Qualifier properties use `pq:` IDs What this returns (TOON text): 1. Ranked schema candidates: - `classes` - `object_properties` - `data_properties` - `qualifier_properties` Each item includes core entity metadata and score. 2. A Steiner-style schema snippet for composition: - `subgraph`: triples (`subject_class`, `predicate_property`, `object_class`) - `data_properties`: dictionary keyed by data property -> list of mapped classes - `qualifiers`: dictionary keyed by qualifier -> list of `{ "subject_class", "qualified_property" }` Use the returned IDs/properties directly in SPARQL. This tool returns schema guidance, not full instance retrieval.
STAGE 2: query MathModDB Wikibase data with SPARQL. Prerequisite: run `explore_ontology` first to get valid `wd:`, `wdt:`, and `pq:` IDs. Rules: 1. Prefixes are preconfigured; do not declare PREFIX blocks. 2. Always include `LIMIT` (recommended <= 50, hard max 100). 3. Prefer small, focused queries and iterate. Common patterns: - Instance/class: `?item wdt:P31 wd:QClassID` - Property filter: `?item wdt:PX ?value` - English label: `?item rdfs:label ?label . FILTER(LANG(?label) = "en")` Batch mode is preferred for multiple related requests: - Pass a dictionary: `{ "name1": "SELECT ...", "name2": "SELECT ..." }` - Response keys match your dictionary keys.
Input schemas lack formal JSON Schema type declarations. Parameter annotations use Annotated[str, description] but do not declare parameter types, required fields, enums, or constraints in a machine-readable format. LLMs infer types from context, increasing hallucination risk.
Output schemas are not documented. Tools return strings (TOON-encoded structured text, SPARQL JSON results) but the expected structure, fields, and nested objects are not formally specified. Agents cannot plan downstream operations without trial-and-error parsing.
No error handling or recovery guidance. Tools provide no categorization of failure modes (retryable vs. user-fixable vs. fatal), no actionable error messages, and no guidance for next steps after failure. A SPARQL timeout, malformed query, or rate limit hit would return a raw error with no recovery path.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Missing tool annotations despite clear safety profile. All three tools are read-only operations against a knowledge graph. The fastmcp framework and MCP protocol support readOnlyHint/destructiveHint/idempotentHint annotations that should be applied to clarify semantics and enable agent optimization.
Parameter naming inconsistency: 'query' vs 'queries'. Explore_Ontology and SPARQL_Query both use 'query' (singular string), but Batch_SPARQL_Query uses 'queries' (dict). For consistency and clarity, consider standardizing parameter names or adding a prefix to distinguish single-query from batch-query tools.
Explore_Ontology query parameter lacks constraints. Description provides good/bad examples but no formal enum or regex pattern. An LLM could pass a 100-word philosophical essay instead of a 2-8 word schema intent, wasting tokens and producing irrelevant results.
SPARQL_Query and Batch_SPARQL_Query lack result pagination/limiting guidance beyond LIMIT clauses. Tools mention LIMIT but provide no guidance on result truncation, total count return, or next_cursor for continuation. Large result sets could exhaust context windows.