gkb-seo-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for HTTP server (default 3000) | |
| GKB_SEO_ROOT | No | Root directory of the GKB SEO project |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| gkb_rules_indexA | Compact table of all 56 rules: code + title + 1-line purpose + category + always_on + NEW v7 fields (intents, atomic_set, output_element). Use first to see what exists. |
| gkb_rule_detailA | Full text of a single rule by code (R01..R56) + v7 machine metadata (intents, triggers, atomic set + full set members, expected output element). Full text is read from data/rules/rule_texts/.md when migrated; falls back to purpose_1line with a migration note. |
| gkb_rules_by_purposeA | Filter the 56-rule table by purpose bucket: structure | lexical | EEAT | unique | all. Specific buckets exclude off-topic rules (R31/R32). |
| gkb_coverage_reportA | Introspection: intent→rules map, rule→intents map, orphan rules (unreachable via any intent), atomic-set integrity, and matcher trigger inventory. Run after ANY edit to data/*.json. v6 had no such tool — which is how 32 of 56 rules stayed unreachable unnoticed. |
| gkb_smart_orchestrateA | Suggest rules for a heading (retriever+suggester, NOT a decider). v7 contract: matched:false means ZERO candidates + disambiguation_questions (no silent generic set). Atomic sets are served COMPLETE (TABLE_SET incl. R14 outro; STEP/LIST incl. R10 outro). why_matched names the exact trigger tokens. For Sales/homepage sections ALWAYS pass section_role — sales headings are benefit statements with no intent keywords and cannot be classified from text alone. expected_document_shape feeds the writing skill's G42 structure-parity gate. |
| gkb_preset_forbiddenA | Forbidden Guard — restricted terms + lexical rules (LEX-002/003), payload inlined. Returns records WITH inlined content (v7 payload contract). |
| gkb_preset_ilgA | ILG Quick Pick — internal-link rules + examples (PI 6.3.034/035), payload inlined. Returns records WITH inlined content (v7 payload contract). |
| gkb_preset_techB | Tech QA — technical SEO signals. Returns records WITH inlined content (v7 payload contract). |
| gkb_preset_topicalC | Topical Strategy — topical mapping guidelines. Returns records WITH inlined content (v7 payload contract). |
| gkb_preset_qualityA | Quality Control — validation + system status. Returns records WITH inlined content (v7 payload contract). |
| gkb_indexA | Extract metadata from knowledge .md files (GKB_KB_DIR) into gkb_index.jsonl (GKB_INDEX_PATH). v7: clean title extraction — skips markdown noise and AI-conversation openers, prefers the first real heading. The only tool that writes by default; degrades to in-memory with a warning if the index path is not writable. |
| gkb_manifestA | Summarise the index: totals by family, type, language. PURE READ — result returned in the response (v6 crashed with EPERM trying to write gkb_manifest.json into CWD). Pass persist:true to also snapshot into GKB_OUTPUT_DIR (best-effort, warns on failure). |
| gkb_queryA | Filter metadata-only records by family/type/tag/keyword/pi_code/id (stateless, no full content). |
| gkb_micro_queryA | Progressive disclosure: pipe-delimited rows |
| gkb_read_kb_contentB | Read full content from a KB file — v6 contract preserved: {filename, offset, limit} line-based → {content, total_lines, has_more}. v7: filename also accepts a record id (e.g. LEX-002); path resolves via GKB_SEO_ROOT/KB or GKB_KB_DIR (v6 hardcoded __dirname/KB and ignored the env root). |
| gkb_relateA | Jaccard keyword similarity between one record and the rest of the index. |
| gkb_validateA | Check all indexed files exist and SHA256 hashes match. PURE READ — returns {ok, missing, hash_mismatches} in the response (v6 crashed writing runlog.json to CWD). persist:true snapshots to GKB_OUTPUT_DIR, best-effort. |
| gkb_batch_processB | Execute multiple operations in one call — types: query | smart_orchestrate | micro_query | validate | manifest. Response keeps the v6 envelope {summary,results,errors,timestamp}. smart_orchestrate ops accept v7 params (section_role, intent_override, unique_angle, max_intents). |
| gkb_batch_content_generationA | Orchestrate rules for MULTIPLE headings in one call (whole outline / whole homepage). Each item accepts the full v7 orchestrate params. include_relations:true adds shared-rule analysis across headings (which atomic sets repeat, which intents dominate) — useful for structure variety checks. |
| gkb_bulk_analysisC | Analyze multiple text targets: mode 'keyword_extraction' (top domain keywords per text), 'rule_mapping' (orchestrate per text = heading), or 'content_analysis' (length + KB keyword overlap). Kept from v6 for compatibility. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
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.
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.
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.
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.