montology
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MONTOLOGY_MODEL_URL | No | Optional URL of a served model endpoint used by monty gen when no host agent is present. |
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ontology_checkA | Is this name free, defined, or ruled on? Run BEFORE naming anything. |
| ontology_wordsB | The vocabulary as rows (kind: core | inner | adopted | custom | empty for all). |
| ontology_addB | Author a word — check-first: a taken name is refused with findings. Re-renders the words skill on success. |
| scan_surfaceC | What the code declares: counts by language, skips said out loud. |
| scan_candidatesC | Vocabulary the codebase is asking for: recurring declared names with no word. |
| ontology_lintC | The gate: collisions, code resolution, drift — each FAIL carries its repair. |
| structural_searchA | ast-grep over the repo: a pattern that PARSES, e.g. 'def $F($$$)' with lang=python. |
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 7 tools
Tools are largely distinct: check/words/add target the ontology, scan_surface/scan_candidates focus on code analysis, lint is a holistic gate, and structural_search is clearly separate. Minor overlap exists between ontology_check (single name) and ontology_lint (overall issues), but contexts are clear.
Naming mixes prefixes: ontology_check, ontology_words, ontology_add, ontology_lint use 'ontology_' while scan_surface and scan_candidates use 'scan_', and structural_search is standalone. Patterns also vary between verb-based (check, add, lint) and noun-like (words) or adjective-noun (structural_search).
With 7 tools, the surface is well-scoped for managing a code ontology: basic CRUD (check, words, add), scanning (surface, candidates), validation (lint), and advanced search (structural_search). Not overly large or thin.
Core workflows (check, add, list, lint, scan) are covered, but the set lacks update/delete operations for words (only add exists) and no way to view details of a single word beyond listing. This leaves minor lifecycle gaps, though most typical use cases are supported.