ontoprune-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| prune_contextA | Extracts a minimal, hallucination-resistant context contract for a given function or method. Reduces input tokens by >80% while preserving exact type signatures and dependencies across project modules. Args: file_path: Absolute or relative path to the Python source file. target_symbol: Identifier of the function or method (e.g. 'procesar_orden' or 'OrderService.procesar_orden'). format: Desired output format: 'stubs' (default, optimal for code LLMs), 'turtle' (RDF), 'json', or 'nl'. include_body: Whether to include the raw source code body of the target function. project_root: Optional root directory of the project (auto-detected if omitted). Returns: The compact pruned contract string. |
| verify_responseA | Verifies LLM-generated code against an ontological software contract to detect hallucinated or unauthorized method/function calls. Args: response_code: The Python code snippet or markdown text produced by the model. contract_or_file: Either the rendered contract string OR the path to the original Python file. target_symbol: If contract_or_file is a file path, specify the target symbol to extract its contract. Returns: Dictionary with validation status, count of violations, and list of invalid calls. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: prune_context extracts a compact contract from source code, while verify_response validates LLM-generated code against such a contract. Their descriptions and argument sets make the boundary unambiguous.
Both names follow a consistent verb_noun pattern in snake_case: prune_context and verify_response. There are no mixed conventions or vague verbs.
Two tools is slightly below the typical 3-15 sweet spot, but each tool is substantial, non-redundant, and directly supports a focused extract-and-verify workflow. The set does not feel bloated or padded.
The pair covers the core lifecycle of extracting a contract and verifying code against it, with flexible input options for files or rendered contracts. Minor gaps exist for symbol discovery, batch pruning, or contract management, but agents can work around them.