gkb-seo-mcp-server

Server Quality Checklist

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

Latest release: v7.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: batch generation, batch processing, bulk analysis, coverage reporting, indexing, manifest summary, micro query, multiple presets for different aspects, query, read content, similarity, rule detail, rule filtering, rule index, smart orchestration, and validation. No significant overlap.
Naming Consistency5/5
All tools follow the `gkb_` prefix with consistent snake_case naming. Most use a verb_noun pattern (e.g., `batch_process`, `read_kb_content`, `smart_orchestrate`). Minor compound names like `rules_by_purpose` are still consistent with the overall style.
Tool Count4/5
20 tools is slightly high but justified by the complexity of the SEO knowledge base domain. Each tool covers a specific function, and there is no redundancy. A few tools could potentially be merged (e.g., the preset tools), but the count is still reasonable.
Completeness4/5
The tool surface covers core operations: content generation, batch processing, analysis, introspection, indexing, query, validation, and rule management. Minor gaps exist (e.g., no explicit update or delete tools for KB items), but the server's primary purpose is reading/analyzing the KB, and the descriptions imply external editing of data files.
Average 3.9/5 across 20 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety and idempotency. The description adds that it operates 'per text' and is kept for compatibility, but does not disclose further behavioral traits like response format or side effects. With annotations present, the description meets the minimum bar.
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 at two sentences, with the primary action in the first sentence. The second sentence adds a compatibility note. There is no wasted text, though the structure could be more formalized.
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?
Given the tool's complexity (multiple modes, array input, no output schema), the description is insufficient. It does not explain the return format, pagination, or error handling. The compatibility note hints at legacy status but does not clarify what a successful invocation produces.
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 description coverage is 0%, requiring the description to compensate. It adds meaning to the 'mode' parameter by explaining each enum value's function, but provides no additional semantics for the 'targets' parameter (array of objects). The description repeats schema information for mode without enhancing understanding of the input structure.
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 the tool analyzes multiple text targets and lists three specific modes (keyword_extraction, rule_mapping, content_analysis) with brief explanations. It distinguishes the tool's function but does not explicitly differentiate from many sibling tools like gkb_query or gkb_smart_orchestrate.
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 provides no guidance on when to use this tool versus alternatives. It only mentions modes and a compatibility note. Given many siblings with overlapping capabilities, the lack of selection criteria is a significant gap.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that records contain inlined content (v7) and that the 'inline' parameter controls metadata-only output. However, it does not disclose other traits like pagination, result size limits, or error conditions.
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?
Two sentences with minimal waste, though the first sentence essentially repeats the title. The second sentence provides the core behavioral information. Could be slightly more concise by merging or removing redundancy.
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 tool with one optional parameter and no output schema, the description is minimally adequate: it explains the return type and the parameter's effect. However, it lacks context about what 'records' represent, the meaning of 'topical mapping guidelines', and any assumptions about data volume or 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?
Schema coverage is 100% and the schema description ('false → metadata-only (legacy v6 shape)') already explains the inline parameter. The tool description adds 'v7 payload contract' context but does not significantly extend parameter understanding beyond the schema.
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?
Description states 'Returns records WITH inlined content (v7 payload contract)', which clarifies the output format, but the primary purpose of retrieving topical mapping guidelines is only implied by the title. It doesn't explicitly state what the tool does (e.g., list, retrieve, generate) and lacks differentiation from sibling preset 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?
No guidance on when to use this tool versus alternatives like gkb_preset_forbidden or gkb_preset_quality. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that records are returned with inlined content (v7) and mentions the inline parameter controlling legacy v6 behavior. This clarifies the payload version but does not reveal other behavioral traits beyond annotations.
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?
Very concise: two short sentences. No filler or repetition. Could potentially include more detail without harming conciseness, but current structure is efficient.
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?
The tool is simple (one boolean param, no output schema). The description covers the payload contract versions. However, it does not explain what 'technical SEO signals' means in terms of data fields, nor does it contrast with sibling tools. Adequate for basic use but lacks depth.
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?
Schema coverage is 100% with the inline parameter having a clear description. The description reinforces that inlined content is the default (v7) and metadata-only is legacy v6, but adds little new meaning beyond the schema.
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 the tool returns records with inlined content (v7 payload) for technical SEO signals. The title 'Tech QA — technical SEO signals' gives a distinct purpose, differentiating it from sibling presets like quality or topical. However, it doesn't elaborate on what 'technical SEO signals' includes.
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 on when to use this tool versus sibling presets (e.g., gkb_preset_quality, gkb_preset_topical). The description does not specify suitable scenarios or exclude alternatives.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds response envelope info but omits execution behavior (sequential/parallel), error handling, or partial failure details.
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 concise sentences, front-loaded with key purpose, list of types, and response format. No redundant phrasing.
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?
Covers operation types and response envelope, but for a complex batch tool with nested schema, more details on error handling, operation semantics, and use-case guidance are needed.
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?
Schema has 0% description coverage. Description adds operation types and v7 params for smart_orchestrate, providing useful context beyond bare schema. Still lacks per-operation parameter details.
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?
Clearly states 'Execute multiple operations in one call' and lists operation types, establishing purpose. However, does not differentiate from sibling batch tools like gkb_batch_content_generation or individual operation 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?
No explicit guidance on when to batch operations vs. using individual tools. Missing indications of prerequisites or exclusions.
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?
Annotations already declare readOnlyHint and idempotentHint, but the description adds useful behavioral context: line-based reading with offset/limit, v6 vs v7 path resolution, and acceptance of record IDs. This goes beyond the annotations and helps the agent understand side-effect-free read behavior.
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 two sentences but includes technical version details (v6/v7 contracts, env paths) that may not be essential for an AI agent. The main purpose is front-loaded, but the extra detail could be streamlined to improve brevity.
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?
The description covers input parameters, output format ({content, total_lines, has_more}), and version differences. For a read-only tool with no output schema, this is fairly complete. It lacks edge-case handling (e.g., file not found) but annotations suggest simplicity.
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?
Schema description coverage is 100%, so baseline is 3. The description reinforces parameter meanings (offset, limit, filename) but does not add significantly new semantics beyond the schema. It mentions line-based behavior, which is implicit from parameter names.
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?
Clearly states the tool reads full content from a KB file with optional line-based offset/limit. The description mentions v6 and v7 contracts, specifying input and output format. However, it does not explicitly distinguish from sibling tools like gkb_query or gkb_micro_query, which could also read content.
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 lacks any guidance on when to use this tool versus alternatives. With 18 sibling tools, including gkb_query and gkb_micro_query, usage context is missing. No when-not-to-use or prerequisite information is provided.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds specific behavioral context: it returns records with inlined content (v7 payload contract) and focuses on restricted terms/lexical rules, which is useful but not critical beyond annotations.
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?
Two sentences with no wasted words, though the first sentence repeats the title. Still concise and front-loaded with key 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 read-only preset tool with a single parameter and no output schema, the description adequately states what records are returned and their content type. Missing details like pagination or ordering are acceptable given the simplicity and annotations.
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?
Schema coverage is 100% with one boolean parameter 'inline' already described as 'false → metadata-only (legacy v6 shape)'. The description does not add any extra meaning or usage guidance for this parameter, so baseline of 3 is appropriate.
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 explicitly states the tool returns records with inlined content for restricted terms and lexical rules (LEX-002/003), and uses a distinctive name 'Forbidden Guard' that sets it apart from sibling preset tools (e.g., gkb_preset_ilg, gkb_preset_quality). This provides clear verb+resource+scope differentiation.
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 on when to use this tool versus alternatives. The description simply states what it does without explaining scenarios where it should be preferred over sibling tools like gkb_preset_topical or gkb_preset_tech.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Description adds value by clarifying the response includes inlined content and mentions v7 payload contract, which goes beyond annotations.
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, no wasted words. Key information is front-loaded in both title and description.
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 single-parameter read-only tool with no output schema, the description covers the main return format but lacks explanation of what 'quality control' records contain or how they relate to validation/system status.
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?
Schema coverage is 100% with clear description for the inline parameter. Tool description reinforces the default behavior (inlined content) but adds minimal new meaning beyond the schema's own description.
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?
Title and description clearly indicate this tool returns quality control/validation records with inlined content. However, it does not strongly differentiate from siblings like gkb_validate or gkb_query, which may also return similar records.
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 on when to use this tool versus alternatives. The description simply states what it does without specifying context 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the specific algorithm (Jaccard) and scope (rest of index), which is useful but does not contradict annotations. It does not fully describe behavior such as output format or sorting.
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 concise sentence with no unnecessary words. It effectively communicates the core functionality without repetition or excess.
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 (2 params, no output schema, safe annotations), the description is largely sufficient. However, it could be more complete by indicating the output format (e.g., list of records with similarity scores sorted descending). Still, it provides the essential context for an AI agent.
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 description coverage is 50% (only 'id' has a description). The description does not mention the 'limit' parameter or its default/range. It provides no additional meaning beyond the schema for 'id', and fails to compensate for the undocumented 'limit' parameter.
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 computes Jaccard keyword similarity between a given record and all others in the index. It uses specific verbs and resources (compute similarity, record, index), distinguishing it from siblings like gkb_query or gkb_read_kb_content.
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 explicit guidance on when to use this tool versus alternatives. The description implies usage for finding similar records, but does not mention prerequisites, when not to use, or how it differs from other similarity-related tools among siblings.
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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by specifying that the tool returns records with inlined content (v7 payload contract) and that the inline parameter controls metadata-only (v6 shape). This covers behavioral nuances beyond annotations.
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, no fluff. The first sentence serves as a title repetition, the second adds key behavior. Every word earns its place, and the structure is front-loaded with the tool's identity.
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 well-covered annotations, the description is largely complete. It explains the payload contract and versioning. However, it does not mention the output schema or any pagination details, which is acceptable given no output schema exists.
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 covers the single parameter with 100% description coverage, stating that false yields metadata-only. The description reinforces this by noting v7 vs v6 payload contracts, adding minor context. Since schema already does the work, score is at baseline.
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 the tool returns records with inlined content for internal-link rules and examples. The title reinforces the 'quick pick' nature, making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling preset tools, leaving room for ambiguity.
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 provides no guidance on when to use this tool versus alternatives. With 19 sibling tools including other presets, the lack of contextual usage hints or exclusions makes it difficult for an AI agent to choose correctly without external knowledge.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the return shape ({ok, missing, hash_mismatches}), noting a historical crash (v6 issue), and explaining the persist behavior with a best-effort note. No contradictions with annotations.
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 three sentences with no fluff. The first sentence immediately states the core purpose, the second clarifies read-only nature and output format, and the third addresses the parameter. Front-loaded and efficient.
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 one optional parameter, existing annotations, and no output schema, the description covers the essential behavioral context: what the tool does, its return structure, and parameter semantics. The historical crash note adds useful context, making it sufficiently complete for a simple tool.
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 the description must explain the only parameter 'persist'. It does so by describing its effect ('snapshots to GKB_OUTPUT_DIR') and noting 'best-effort', adding meaning beyond the schema's type and 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 states a clear, specific action: checking file existence and SHA256 hashes. However, it doesn't explicitly differentiate from sibling tools like gkb_index, which also deals with file integrity, but the verb 'validate' and the specific checks provide adequate purpose clarity.
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 explicit guidance on when to use this tool versus alternatives. The note about a v6 crash and persist behavior hints at context but does not provide clear when-to-use or when-not-to-use instructions.
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?
Discloses rich behavioral details beyond annotations: matched:false behavior, atomic set completeness, why_matched naming trigger tokens, and section_role necessity for Sales pages. Annotations already indicate read-only and idempotent, and description adds significant 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?
Front-loaded with core purpose, then dives into contract details. Slightly verbose with version-specific specifics, but still efficient. Could be tightened without losing clarity.
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?
Covers behavioral contract and section_role guidance, but lacks explanation of the output format of suggested rules. Since there is no output schema, the description should describe what the tool returns; mentions why_matched and expected_document_shape but not the overall suggestion 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?
While schema coverage is high (80%), the description adds value for section_role by emphasizing its necessity on Sales pages, but does not elaborate on unique_angle or intent_override beyond the schema descriptions. Baseline 3 with marginal improvement.
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 the tool suggests rules for a heading, and specifies it's a retriever+suggester not a decider. It includes contract details but could more explicitly differentiate from sibling tools like gkb_query.
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?
Provides specific guidance on passing section_role for Sales/homepage sections, and mentions expected_document_shape. However, lacks explicit when-to-use vs alternatives or exclusion criteria, leaving the agent to infer usage context.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context ('stateless, no full content'), which explains why it's a lightweight query. No contradictions.
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?
One concise sentence (20 words) that front-loads the core functionality and constraints. No redundant information.
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?
With 7 parameters, no required, and no output schema, the description is minimal. It does not cover pagination, error handling, or result structure. While adequate for a simple filter, it leaves gaps for a complex schema.
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?
Schema coverage is 57%, so the description partially compensates by listing filter fields. However, it does not explain parameter combinations, format requirements, or how limit/pagination works. Schema provides descriptions for some params like type and family, so description adds marginal value.
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 filters metadata-only records by specific fields (family, type, tag, keyword, pi_code, id) and explicitly notes it is stateless with no full content. This distinguishes it from siblings like gkb_read_kb_content.
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 metadata-only lookups via 'no full content' but does not explicitly state when to use this tool instead of siblings like gkb_micro_query or gkb_read_kb_content. No when-not-to-use guidance is provided.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that include_relations provides shared-rule analysis, but does not disclose additional behavioral traits like response format or error handling. No contradiction with annotations.
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, front-loaded with the core purpose. Every phrase adds value, with no wasted words. The second sentence efficiently explains the optional parameter.
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 2 parameters with nested objects and no output schema, the description covers the batch scope and optional feature. It doesn't mention constraints like maxItems=40 (visible in schema) or explicitly state the return value, but is otherwise complete for an idempotent, read-only tool.
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% schema description coverage, the description compensates by explaining the 'items' array contains 'full v7 orchestrate params' and that include_relations adds cross-heading analysis. This adds meaning beyond the schema, though the exact shape of items is partially inferred from the schema itself.
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 orchestrates rules for multiple headings in one call, distinguishing it from single-headline tools. The verb 'orchestrate' and resource 'rules for multiple headings' are specific and actionable.
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 implies use for batch operations on whole outlines or homepages and mentions the include_relations feature for structure variety checks. However, it does not explicitly contrast with sibling tools like gkb_smart_orchestrate or state when not to use it.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying data sources and fallback behavior (reading from markdown file or returning purpose_1line with note), which is not covered by annotations.
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?
Three sentences, front-loaded with the main purpose. Every sentence adds unique information without redundancy. No unnecessary 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?
No output schema exists, but the description fully explains the return value: full text (or fallback) plus v7 machine metadata including intents, triggers, atomic set members, and expected output element. For a simple read-only tool with one parameter, this is complete.
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 100%, so the description's job is minimal. It adds the valid code range (R01..R56) beyond what the schema provides (pattern and description). This helps the agent understand acceptable inputs.
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 'Full text of a single rule by code (R01..R56) + v7 machine metadata', specifying the exact verb (retrieve full text and metadata), resource (rule by code), and scope (valid codes range). It inherently distinguishes from sibling tools that deal with batches, indexes, or purposes.
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 context about fallback behavior during migration, which helps the agent understand when full text is available. However, it does not explicitly state when to use this tool versus alternatives like gkb_rules_index (for listing) or gkb_rules_by_purpose (for filtering by purpose).
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool is for introspection, confirming it is read-only and non-destructive. It provides further behavioral context about what the report contains (maps, integrity, etc.), enhancing transparency.
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, using two sentences to convey purpose, usage trigger, and historical context. Every sentence adds value with no redundancy.
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 no parameters and no output schema, the description fully covers tool purpose, usage context (after edits), and specific outputs. It also explains the tool's necessity via the v6 anecdote, making it complete.
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?
There are zero parameters, so the schema covers 100%. The description adds no param details but explains the tool's output sufficiently. Baseline for 0 params is 4, and the description is clear without needing param info.
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 provides an introspection report covering intent-rules mapping, rule-intents mapping, orphan rules, atomic-set integrity, and matcher trigger inventory. It differentiates from sibling tools by being a coverage report, and the specific outputs are listed.
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?
It explicitly instructs running after any edit to data/*.json and contrasts with v6 to highlight the tool's value. While it doesn't list when not to use it, the context is clear. No explicit alternatives are given, but the purpose is distinct from siblings.
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?
Annotations indicate idempotentHint=true and destructiveHint=false; description adds that it 'writes by default' and 'degrades to in-memory with a warning' if path not writable. This goes beyond annotations without contradiction.
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, concise yet informative, with the core action front-loaded. 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 0 parameters and no output schema, the description covers purpose, behavior, and writability edge case. Complete for the tool's 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?
Input schema has 0 parameters, so the description correctly omits parameter details. Baseline 4 applies as no extra param info needed.
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 clearly states 'extract metadata from knowledge .md files into gkb_index.jsonl', specifying the verb 'extract' and resource 'knowledge .md files'. It distinguishes itself from siblings by noting it's 'the only tool that writes by default'.
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 implies when to use: when you need to rebuild the index from .md files. It provides context on the index path and mentions fallback to in-memory if unwritable, but does not explicitly state when to avoid this tool or suggest alternatives.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds value by specifying the output fields and that it returns a compact table of all rules. No contradiction.
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, front-loaded with purpose and contents. No redundant information.
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?
With zero parameters and no output schema, the description fully covers what the tool does and when to use it. Low complexity tool, description is complete.
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?
Zero parameters; baseline score of 4 applies as per rule. No additional parameter info needed.
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?
Describes a compact table of all 56 rules with specific fields (code, title, purpose, etc.) and states its purpose ('Use first to see what exists'). Clearly distinguishes from sibling tools like gkb_rule_detail.
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?
Explicitly says 'Use first to see what exists', indicating it is the initial overview tool before using detailed or filtered tools. Does not explicitly list exclusions, but context provides clear guidance.
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?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds transparency about the output format (pipe-delimited rows) and token limit (~50-100), which is not in annotations.
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 concise sentences, front-loaded with the core concept, no unnecessary words. Efficient and clear.
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 compact query tool, the description covers output format and next steps. It could mention that multiple filters can be combined, but overall complete given the tool's simplicity.
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 57% (4/7 parameters described). The description adds value by revealing that output fields include id, family, type, and title, which aids parameter understanding but does not detail each parameter.
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 returns pipe-delimited rows with id, family, type, title (~50-100 tokens), distinguishing it from sibling tools like gkb_query and gkb_read_kb_content which provide fuller details.
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?
The description explicitly explains progressive disclosure and advises to follow up with gkb_query or gkb_read_kb_content on specific ids, giving clear when-to-use and when-not-to-use guidance.
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?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. Description adds behavioral detail that specific buckets exclude off-topic rules (R31/R32), providing extra context beyond annotations.
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 with no redundant words. The verb 'Filter' and resource are front-loaded, and every part 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?
For a single-parameter read-only tool with full annotations, the description covers all necessary aspects: purpose, valid values, and special filtering behavior. No output schema is needed as return values are implied.
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 100% with an enum, but the description adds meaningful context: the table size (56 rules) and that certain buckets exclude specific rules. This enriches the parameter's semantics beyond the enum list.
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 clearly states the tool filters a specific resource ('56-rule table') by purpose bucket, enumerating valid values and noting exclusion behavior. This is specific and distinguishes it from sibling tools like gkb_rule_detail or gkb_rules_index.
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 explicitly tells when to use the tool (to filter by purpose bucket) and lists valid buckets. It does not mention when not to use it or alternative tools, but the context is clear given the distinct sibling tools.
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?
The description adds behavioral info beyond annotations: declares 'PURE READ', mentions result returned in response, and details the optional persistence behavior including caveats (best-effort, warns on failure, historical crash). Consistent with annotations.
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 concise sentences plus a parenthetical provide all necessary information without any filler. Front-loaded with the main action.
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 simplicity (one boolean parameter, no output schema, rich annotations), the description is fully complete. It covers purpose, usage context, return behavior, and persistence option with edge cases.
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%, but the description explains the single parameter 'persist' clearly: when true it snapshots into GKB_OUTPUT_DIR with best-effort behavior and failure warnings.
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 action (summarise) and the resource (index) with specific breakdowns (totals by family, type, language). It distinguishes itself from siblings like gkb_query or gkb_validate which have different purposes.
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 implies use for summary and notes that it is a pure read. It mentions optional persistence, but does not explicitly state when to use alternatives like gkb_query for detailed queries.
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:

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

Score Badge

Copy to your README.md:

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

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/nuppawat6/KmMcp'

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