montology

by shinyobjectz

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
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 Consistency2/5
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).
Tool Count5/5
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.
Completeness3/5
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.
Average 3/5 across 7 of 7 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 110 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only offers an unclear phrase 'skips said out loud' and no details about side effects, scope, or limitations. The description is far too vague to understand the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks clarity and structure. It reads as cryptic and under-specified, not concise in an effective way. The phrase 'skips said out loud' adds confusion rather than value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what the output represents. The context from sibling tools does not clarify the tool's role, and the description is too incomplete to understand the tool's purpose in the broader ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the high schema coverage (implicitly 100%) means there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description vaguely mentions counting by language but does not specify what is being counted or what 'skips said out loud' means. It fails to clearly state the tool's function, making it indistinguishable from siblings like scan_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not mention side effects, permissions, read-only status, or output format. The phrase 'recurring declared names with no word' hints at the search criterion but not at the behavior of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise. However, it is under-specified; the brevity comes at the cost of clarity. It does not waste words, but it also does not provide enough information to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema and an output schema, so return values are not necessarily needed in the description. However, the core function and purpose are not clearly explained, and the description leaves significant ambiguity. The context provided by siblings like 'scan_surface' and 'ontology_check' does not compensate for the lack of descriptive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'top' with 0% description coverage. The description does not mention 'top' at all, failing to explain that it likely controls the number of results. The description adds no semantic value beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Vocabulary the codebase is asking for: recurring declared names with no word' provides a specific focus but lacks an explicit verb or clear action statement. It implies the tool identifies candidates for vocabulary additions, but does not state that it scans or returns them. This makes the purpose clear in a vague sense, but it does not explicitly distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. It only defines the topic of the scan, leaving the user to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only cryptically states that 'each FAIL carries its repair,' suggesting the tool outputs failures with repair instructions, but it does not explain side effects, permissions, or what 'collisions,' 'code resolution,' and 'drift' concretely mean. This is insufficient for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise with no unnecessary words. However, its cryptic and metaphorical phrasing means it is not well-structured for immediate comprehension; it is under-specified rather than efficiently clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too vague to understand what the tool actually does or how it fits into a workflow. It does not explain what inputs it operates on, what 'gate' implies, or how the listed concepts (collisions, resolution, drift) are detected or repaired. The description is incomplete for a tool with this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score is 4. The description does not need to explain parameters, and it adds no param-related information, which is acceptable given there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description calls the tool 'The gate' and references collisions, code resolution, and drift, which hints at a validation or linting role. However, it lacks a specific verb like 'checks' or 'validates', and the metaphor makes the exact operation ambiguous. It gives some sense of purpose but remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the sibling tools such as ontology_check, ontology_words, or ontology_add. There is no mention of prerequisites, context, or scenarios where this tool is preferred, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral disclosure. It does not state whether the operation is read-only, how results are ordered, whether pagination applies, or any side effects. The safety profile is entirely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is not a complete sentence and omits an explicit action. The phrase 'empty for all' is terse but ambiguous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with an output schema, the description is minimally adequate, but it does not clarify what 'vocabulary' refers to or how this tool fits into a workflow. It could be more helpful with an explicit verb and usage hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'kind' parameter by enumerating possible values (core, inner, adopted, custom) and explaining that empty string returns all. This goes beyond the schema, which only declares a string with a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (vocabulary) and output shape (rows) with a filter dimension (kind), making its purpose reasonably clear despite lacking an explicit verb. It does not explicitly distinguish itself from sibling tools like ontology_check or ontology_add, but the semantics are distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The mention of 'empty for all' implies an optional filter, but there is no context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses key side effects—check-first refusal and re-rendering the words skill on success—which is good. Yet it stops short of explaining what 'findings' contain, how failures are returned, or any permission or idempotency details, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence broken by a dash, with a second short sentence. It is front-loaded with the main action and includes only high-signal details, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no annotations, the description is too brief to be fully actionable. It covers the primary behavior and side effect but does not explain required inputs, optional parameters, or the structure of 'findings,' despite an output schema existing. The low schema coverage makes this a significant shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description was expected to compensate by explaining parameters. It only mentions 'word' and 'taken name,' which vaguely maps to 'name' and 'definition' but leaves 'code', 'kind', 'test', and 'owner' entirely undocumented. This adds no meaningful parameter semantics beyond the property names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'author' with the resource 'word' and explicitly states the check-first behavior ('a taken name is refused with findings'), making its primary action clear. It distinguishes itself from siblings like ontology_check and ontology_words by focusing on creation with a built-in existence check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding new words ('Author a word') and that it performs a check first, which suggests it should be used instead of calling ontology_check separately. However, it does not explicitly contrast with alternatives or state when not to use it, leaving the guidance at the implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It implies a read-only status check without side effects, but does not explicitly state safety, define the outcomes (free/defined/ruled on), or mention error conditions. It provides basic behavioral context but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that delivers the core purpose and usage directive without wasted words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter check tool with an output schema, the description provides adequate context: what it checks, when to run it, and the possible outcomes. It lacks definitions of 'ruled on' and explicit read-only assurance, but given the tool's simplicity and existing output schema, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only indirectly references the parameter via 'this name'. It does not explicitly explain the parameter format, constraints, or semantics beyond implying it is the name to check. The possible statuses add minimal context, but the description fails to fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear question form to indicate the tool checks whether a name is free, defined, or ruled on. It implies a check action and the resource (name in ontology), distinguishing it from siblings like ontology_add (adding) and ontology_lint (linting). Missing an explicit verb like 'checks' but still understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Run BEFORE naming anything' explicitly tells when to use the tool, establishing it as a prerequisite check. It does not mention alternatives or exclusions, but the timing guidance is clear and context-rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully highlights that the tool PARSES (rather than text-matches) and operates repo-wide, but does not disclose read-only status, error behavior for invalid patterns, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence front-loads the core functionality and uses an example to clarify usage. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers purpose, scope, and gives a practical example. Missing details about pattern syntax and lang defaults are parameter-level and do not severely undermine completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage). The description adds meaning by mentioning 'pattern' and 'lang' via a concrete example, implicitly defining pattern as a structural code pattern and lang as a language selector, though it doesn't fully enumerate allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as ast-grep for structural search over the repo, with a concrete pattern example and language specification. This distinguishes it from the sibling ontology and surface-scanning tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for syntactic/code-pattern search ('over the repo'), but it does not explicitly state when to use this tool over alternatives, nor provide any exclusions or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![montology MCP server](https://glama.ai/mcp/servers/shinyobjectz/montology/badges/card.svg)](https://glama.ai/mcp/servers/shinyobjectz/montology)

Score Badge

Copy to your README.md:

[![montology MCP server](https://glama.ai/mcp/servers/shinyobjectz/montology/badges/score.svg)](https://glama.ai/mcp/servers/shinyobjectz/montology)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shinyobjectz/montology'

If you have feedback or need assistance with the MCP directory API, please join our Discord server