Loading ToolBench
Local MCP server for OntoSkills ontologies. Provides SPARQL-based skill discovery, semantic search, execution plan evaluation, and knowledge node querying over OWL 2 ontologies compiled from SKILL.md specifications.
OntoMCP exhibits critical gaps in schema completeness, description quality, and error handling. While tool naming follows verb_noun conventions (search_skills, get_skill_context, query_knowledge_nodes, evaluate_execution_plan), the server lacks visible input schema definitions in the source code, comprehensive parameter descriptions, and structured output documentation. Four tools are defined with descriptions averaging ~150 chars, which is within baseline (194 chars p50), but parameter-level descriptions are minimal or absent. No error handling guidance is visible. The codebase shows competent Rust/SPARQL implementation but poor adherence to agent-tool composition patterns.
Evaluate whether a skill can be executed given current state constraints and prerequisites
Retrieve full context and metadata for a specific skill including prerequisites, outputs, and related knowledge nodes
Query epistemic and operational knowledge nodes (procedures, code patterns, output formats, commands, prerequisites) with SPARQL filtering
Search for skills by intent, keywords, or skill type using BM25 full-text search and optional semantic embeddings
Input schemas lack comprehensive parameter descriptions. The rubric baseline requires 100% of A+ tool params to have descriptions; here, parameter-level descriptions are minimal. E.g., 'query' in search_skills lacks constraints (max length, example patterns); 'skill_id' lacks guidance on qualified identifier format (what qualifies 'official/create-pdf'?); 'limit' lacks bounds (min 1, max?); 'use_embeddings' lacks context on performance/accuracy trade-offs.
No visible output schemas or response documentation. The rubric requires documented return types (100% of A+ tools). The repository shows Rust implementations using oxigraph/serde but source code provided does not include explicit response shape definitions for any tool. Agents cannot plan downstream calls or extract required fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
No pagination support visible for list-returning tools. search_skills returns multiple results but no limit is enforced in the schema definition, no next_cursor documented, and no offset/page parameters visible. Rubric requires paginated-result pattern for tools returning lists.
Missing error handling guidance. No visible error classification (retryable, user-fixable, fatal) or recovery suggestions. E.g., if a skill_id is not found, the error should suggest 'Call search_skills() to discover available skills', but no such guidance exists.
Parameter dependencies undocumented. query_knowledge_nodes accepts node_type (Procedure, CodePattern, etc.) and filter_content, but the schema does not clarify: Is filter_content free-text search? Is it regex? SPARQL pattern syntax? Do certain node types ignore filter_content? Dependencies require explicit documentation.
Opaque identifier requirements. get_skill_context requires 'qualified identifier' format (e.g. 'official/create-pdf') but the description does not specify: What prefixes are valid? (official, local, verified, community?) What character limits? What if the user only has a skill name? Should they call search_skills first? This forces agents to guess or make extra lookups.
Tool descriptions lack context on common failure modes and recovery paths. E.g., evaluate_execution_plan's description does not explain: What does 'current state' mean? Is it a list of skill IDs already executed? Resource URIs? How are state constraints evaluated (hard blocks vs soft conflicts)?
No idempotence guarantees documented. Agents retry on network failures, if search_skills is called twice with identical parameters, does it return identical results? The description does not state this, forcing agents to assume non-idempotence and avoid retries.