Loading ToolBench
MCP server that extracts domain ontologies from Python codebases
Ontomics provides 12 well-named, read-only tools for domain ontology extraction from codebases. All tools start with action verbs (query_, check_, suggest_, etc.) and have descriptions present. However, schema completeness is inconsistent: several tools lack documented output schemas, parameter descriptions are sometimes generic, and error handling guidance is minimal. The codebase shows careful implementation (e.g., OUTPUT_BUDGET_BYTES constant, parameter validation in handlers), but the tool definitions themselves lack the LLM-optimization rigor needed for A-grade scores. Most tools cluster in the 50-65 range due to missing output documentation and generic descriptions.
Check if an identifier follows project naming conventions. Returns consistent/inconsistent verdict with canonical form.
Describe a function or class without reading its source — returns signature, parameters, callers, callees, semantic role.
Export the project's full domain knowledge as portable YAML — abbreviations, conventions, domain terms, concept associations.
Generate ONTOLOGY.md from the concept graph
List the project's domain vocabulary ranked by importance. A semantic overview of what this codebase is about.
List the project's actual naming conventions detected from code — prefix/suffix patterns, conversion patterns, casing rules.
Output schemas not documented. Tools return JSON responses (visible in handle_query_concept handler: json!({"concept": {...}, "variants": ..., ...})), but the tool definitions in schema do not document these return structures. LLMs cannot plan downstream calls or extract fields without knowing what the response contains.
Parameter descriptions are generic or minimal. Examples: 'Max related concepts (default: 10)' for max_related does not explain what 'related' means semantically; 'Filter by concept' for list_entities is vague about filtering logic. Descriptions should explain WHEN to set each parameter and HOW it affects results.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
Find classes and functions matching a semantic role or concept. Returns entities with semantic roles and concept tags.
Find the best entry points for understanding a concept — ranked shortlist of key functions, classes, and files to read.
Compare the domain ontology between git revisions — shows concepts added, removed, or changed.
Semantic concept lookup — returns variants (including abbreviations), related concepts, naming conventions, function signatures, and file locations.
Generate project-consistent identifier names from a natural language description using the project's actual conventions.
Measure vocabulary health (convention coverage, consistency, cohesion)
No error handling guidance. Handlers return generic error messages like 'missing required argument' or 'unknown tool', but tool descriptions do not document failure modes or recovery steps (e.g., 'If concept not found, try list_concepts() to see available domains'). Agents receive no guidance on what to do next.
Tools with empty input schema (list_conventions, vocabulary_health, generate_ontology_md, export_domain_pack) lack documented behavior for parametrization. If no parameters are accepted, the description should explicitly state 'This tool takes no parameters' rather than leaving it ambiguous.
No pagination documented for list tools. list_concepts and list_entities accept top_k but do not specify whether results are exhaustive, how many total concepts/entities exist, or whether multiple calls with different offsets are supported. Without this, agents cannot reliably discover all available items.