llm-wiki-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a distinct purpose. get_index provides an overview, search_wiki and find_page are explicitly differentiated for full-text search vs. single-page retrieval, and read_page, list_pages, list_types, list_tags, get_log, read_source, validate_wiki, and ask each serve unique functions without overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., get_index, search_wiki, find_page, read_page, list_pages, list_types, list_tags, get_log, read_source, validate_wiki). The only minor deviation is 'ask', but it is still a single verb and fits the pattern of action-oriented names.
Tool Count5/5
With 11 tools, the set is well-scoped. Each tool covers a specific aspect of wiki interaction (index, search, retrieval, listing, logging, raw source access, validation, Q&A) without being excessive or sparse.
Completeness5/5
The tool set is complete for a read-only wiki interface. It provides everything needed to navigate, search, retrieve, validate, and query a wiki corpus. While write tools are absent, the domain inferred from the tool descriptions is clearly read-only, so no gaps exist.
Average 4.3/5 across 11 of 11 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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 GPL 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only notes the file type limitation but lacks details about error handling, encoding, size limits, or permissions. Minimal disclosure.
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?
Two sentences plus a one-line arg description. Each sentence adds value: purpose, file type restriction, parameter meaning. No fluff, front-loaded.
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?
Adequate for a simple read tool with one parameter and an output schema. However, missing info on behavior when path is invalid or points to a directory. Reasonable but not thorough.
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 has 0% description coverage. The description adds 'Path within the raw source directory' for the path parameter, which is basic but insufficient—no format or examples. Does not fully compensate for lack of schema documentation.
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 states the tool returns text of raw source documents, specifying types (transcript, article, notes). It also restricts to text files, which distinguishes from sibling tools like read_page that deal with wiki pages.
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?
Provides explicit constraints: only text files, not PDFs/binaries. This tells when to use (text raw sources) and when not to (binaries). No explicit alternatives named, but context implies other tools for non-raw sources.
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 are provided, so the description must disclose behaviors. It only says 'return...full content' without mentioning error handling, authorization, or side effects. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement and structured Args section. Almost no waste, though the docstring format slightly increases length.
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 single parameter and existence of output schema, the description covers input completely. It does not explain output, but output schema fills that gap. Adequate for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description adds concrete examples and explains the three valid formats (slug, path, wikilink), which is essential and superior to the raw schema.
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 states 'Return a page's full content' specifying the verb and resource. It distinguishes from sibling tools like 'find_page' (search) and 'list_pages' (list) by emphasizing full content retrieval.
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 explains the input format (slug, path, wikilink) but does not explicitly state when to use this tool versus siblings or provide exclusion criteria. Usage context is implied but not direct.
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?
No annotations provided, so the description carries the full burden. It discloses that the output is one-line descriptions and describes filtering behavior. However, it lacks details on pagination, maximum results, or any side effects, which are important for a read operation.
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 concise with a clear summary sentence followed by parameter docstrings. No wasted words, and the most important information is front-loaded.
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 tool has 3 parameters, an output schema exists (so return values need not be explained), and the description covers purpose and parameters well. It is missing potential usage limits or ordering, but these are not critical for a simple list tool. Overall adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, meaning no parameter descriptions. The description adds significant value by explaining each parameter: page_type (with reference to list_types), tags (with reference to list_tags), and match (with examples of 'and' and 'or'). This fully compensates for the schema gap.
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 clearly states it lists pages with one-line descriptions, optionally filtered. It specifies the verb and resource, and implicitly distinguishes from siblings like search_wiki and read_page. However, it could be more explicit about the scope compared to 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter explanations with references to list_types and list_tags, implying when to use those tools. However, it does not explicitly state when to use this tool over alternatives like search_wiki or find_page, leaving some ambiguity for the agent.
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?
No annotations are provided, so the description carries full burden. It accurately states that the tool returns a catalog of all pages with summaries, implying a read-only action. However, it omits details like data freshness or performance characteristics, which are minor for this simple operation.
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 extremely concise at two sentences, with the main purpose front-loaded. Every phrase adds value, and there is no redundancy.
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 tool's simplicity (no parameters, has output schema), the description adequately explains what it returns and when to use it. The existence of an output schema likely details the return structure, so further elaboration is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so the description does not need to add parameter info. Baseline score of 3 is appropriate as no additional meaning is required or provided.
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 states the tool returns the wiki index, a curated catalog of every page with one-line summaries, using specific verb 'Return' and resource 'wiki index'. It distinguishes from siblings like search_wiki and read_page by emphasizing it as a starting point for navigation.
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?
The description explicitly recommends 'Read this first to navigate', giving a clear use case for initial orientation. It does not mention when not to use it, but the sibling tools imply alternatives for specific search or page retrieval tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists all tags, orders by popularity, and returns page counts. It implies read-only behavior. While it could explicitly state it is safe and idempotent, it is sufficient for a simple listing tool.
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?
Two sentences plus an Args section. Front-loaded with the main purpose. Every word adds value. No redundant or tangential information.
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 tool with one optional parameter and an output schema, the description is nearly complete. It covers behavior, ordering, and parameter purpose. The only minor gap is a lack of details on possible values for page_type, but the output schema presumably provides structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the one parameter: 'Optionally restrict to one type.' The schema has 0% coverage and no enum values. While it adds meaning, it does not specify what 'type' refers to (e.g., page types from list_types). More detail would improve the score.
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 states 'List every tag in use with its page count, commonest first.' It identifies a specific verb and resource, distinguishes from sibling tools like list_pages or list_types by focusing on tags and their usage statistics.
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?
Provides explicit guidance: 'Read this before filtering by tag — it is the only way to learn the vocabulary.' This tells the agent when to use the tool (to discover tags before filtering). However, it does not mention alternatives or when not to use it, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that it reads the index, searches, reads relevant content, and synthesizes a cited answer. This indicates it is a compound read operation. However, it does not mention any potential side effects, rate limits, or error conditions, which would improve transparency further.
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 concise (three sentences for the main body, one for the arg) and front-loaded with the primary purpose. Every sentence adds value: purpose, usage guideline, and parameter. No unnecessary words.
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 tool has one parameter and no annotations, the description adequately covers the core behavior and usage context. It mentions the output is a cited answer, and since an output schema exists, explicit return value details are not required. However, it does not address potential limitations or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%—the schema only defines 'question' as a string with title 'Question'. The description's Args section adds 'The question to answer,' which provides a basic semantic but lacks detail on format, constraints, or examples. This partially compensates but remains minimal.
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 states it answers a natural-language question against the wiki and returns a cited answer. It clearly distinguishes from sibling tools like search_wiki by specifying it produces a finished answer, not raw pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you want a finished answer rather than raw pages,' providing clear when-to-use guidance. Also explains the multi-step process (reads index, searches, reads, synthesizes), which helps the agent understand the expected behavior.
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?
No annotations provided, so description must carry full transparency burden. It does not explicitly state if the tool is read-only or has side effects. The list of checks implies non-destructive scanning, but safety profile is not confirmed.
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?
Concise, well-structured with a summary line and bullet-style parameter list. No redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool, description comprehensively lists all checks. Output schema exists, so return format is not needed. Only 2 parameters with clear descriptions. Complete for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameters are well explained: 'path' to optionally scope to a single page, 'limit' for maximum findings. With 0% schema coverage, description fully compensates, making parameters clear.
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?
Description starts with a clear verb ('Check') and specific resource ('wiki'), followed by a detailed list of conformance problems. This easily distinguishes from sibling tools focused on reading, searching, or indexing.
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?
Description implies validation context but does not explicitly state when to use this tool over siblings. However, the listed checks clearly indicate it's for detecting broken links, duplicate slugs, etc., which contrasts with read/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ordering (newest first), content (what was added when, reasoning), and default behavior (small window). No annotations provided, so description carries burden fully. Lacks mention of potential for pagination or performance.
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?
Two clear, concise sentences for purpose, followed by clean argument list. No fluff, every sentence adds value.
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?
Output schema exists, so not required to describe return shape. Covers essential context: ordering, reasoning, default limit. Minor gap: no mention of error handling or empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains both parameters: since as ISO date filter and limit as max entries with default small window, adding critical context missing from schema.
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?
Clearly states it returns the wiki's change log, newest first, and distinguishes from sibling get_index by contrasting 'what the wiki holds' vs 'how it got there'.
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?
Contrasts with get_index to guide selection, mentions optional since and limit arguments, and notes default small window for logs. Could be more explicit about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description provides full behavioral transparency by detailing that it lists types, includes counts, and explains the derivation logic (frontmatter `type` then directory fallback). This exceeds required disclosure for a read-only list operation.
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 two sentences, front-loading the purpose and adding key behavioral detail about type derivation. Every word adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is complete. It explains the source of types and the inclusion of counts, which is sufficient for an agent to understand the tool's function and output without further detail.
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?
With 0 parameters, the description does not need to add parameter semantics. According to the rubric, baseline is 4, and no additional information is required.
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 states the tool lists page types with counts, specifying the source from frontmatter `type` field with fallback to directory. This distinctively separates it from sibling tools like list_pages or list_tags.
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?
The description implicitly guides usage by explaining what the tool returns (types with counts) and how types are derived. While it does not explicitly mention when not to use it, the context of sibling tools combined with the description provides sufficient guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses search behavior (case-insensitive, regex accepted), excludes raw sources, and returns snippets. It does not mention pagination or result limits, but for a search tool this is adequate.
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?
Two brief paragraphs: one for purpose and return format, one for parameter details. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, 1 required), the description covers search behavior, parameter details, return type (snippets), and exclusion of raw sources. Output schema exists, so return details are not required in description. Sibling references provide alternative usage.
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?
Schema coverage is 0%, so description compensates. It explains query as case-insensitive and regex-accepted, and page_type as an optional type filter with reference to list_types. This adds meaning beyond the plain schema types.
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 states it performs full-text search across the wiki, excluding raw sources, and returns matching files with line snippets. It distinguishes from sibling find_page by noting that find_page is for retrieving a single page rather than every mention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions when to use find_page instead, and provides guidance on the optional page_type filter by referencing list_types for available filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns a single page (not multiple), returns it 'in full', and mentions optional filters. However, it does not explain how the 'best match' is determined, which is a behavioral 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 concise yet thorough. It front-loads the main purpose and usage guidance, then lists parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 the main part (topic search) and optional filters, distinguishes from siblings, and provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides clear explanations for all parameters: topic (with example), page_type (with cross-reference to list_types), tags (with cross-reference to list_tags), and match (explains 'and' vs 'or' semantics). This adds significant meaning beyond the schema.
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 states 'Return the single page that best matches a topic, in full' which clearly specifies the verb, resource, and scope. It also distinguishes itself from the sibling 'search_wiki' by indicating it returns the single best match rather than all mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use this for "what does the wiki say about X".' And when not to: 'Use search_wiki when you want every mention of X across the corpus.' This provides clear context and alternatives.
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:

[![llm-wiki-mcp MCP server](https://glama.ai/mcp/servers/kleinmatic/llm-wiki-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kleinmatic/llm-wiki-mcp)

Score Badge

Copy to your README.md:

[![llm-wiki-mcp MCP server](https://glama.ai/mcp/servers/kleinmatic/llm-wiki-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kleinmatic/llm-wiki-mcp)

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/kleinmatic/llm-wiki-mcp'

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