Server definition
- Hash
- sha256:e82c110a99da7b9be3fc8575c1ae5ef63b0776f236f4835ab79b995d4d1881b6
- What it is
- What a remote MCP server returned when asked what it offers: 1 tools
The blob, as servednamed by its sha256
{
"instructions": "# Codeguide MCP Server\n\nThis MCP server provides **mandatory** coding guidelines and best practices. The guides define coding standards that **must be followed** when writing, reviewing, or modifying code.\n\n## Read on principle: the workflow guide\n\nBefore starting **any non-trivial task** (3+ steps, a new module/algorithm, a refactor, or any behavior change), fetch and apply **`guides://agentic-workflow.md`** as a standing instruction — read it *on principle*, not only when asked. It is the canonical owner of **how you work**: plan-first and re-plan on drift, subagent use and parallel **git-worktree isolation**, the lessons-learned loop (read `docs/lessons.md` before, record corrections after), verification-before-done with an independent second-model **rubber-duck review**, task/checkbox + changelog + docs tracking, configurable constants, and externalized LLM prompts. The language/framework/tool guides govern *what* you write; `agentic-workflow.md` governs *how*. A project's own `CLAUDE.md` / `AGENTS.md` / `CLAUDE.local.md` are authoritative and override it where they differ.\n\n## When to Use\n\n**Before writing or modifying code**, fetch the relevant guides for the project's languages, frameworks, and tools. Apply their standards as mandatory rules — not optional suggestions.\n\nTypical triggers:\n- Starting a new coding task or feature\n- Reviewing or refactoring existing code\n- Setting up a new project\n- When the user asks about coding standards or best practices\n- When there is an explicit request\n\n---\n\n## How to Use This Server (MCP Client)\n\nThe server exposes **resources** and **one tool**. Use standard MCP operations: **ListResources**, **ListResourceTemplates**, **ReadResource**, **ListTools**, and **CallTool**.\n\n### Step 1: Discover guides (always do this first)\n\n- **Read the resource** with URI **`guides://list`**.\n - This returns a text list of all available guides.\n - Each line has the form: `guide_name.md - brief description`\n - Use this list to choose which guides apply to the project (e.g. `python.md`, `rest.md`, `dockerfile.md`).\n\nAlternatively, you can use **ListResources** to see that `guides://list` is available, and **ListResourceTemplates** to see that `guides://{guide_name}` is available.\n\n### Step 2: Get full content for each guide you need\n\nFor each selected guide, get its full content using **either**:\n\n- **ReadResource** with URI **`guides://{guide_name}`** \n Example: read resource **`guides://python.md`** (use the exact filename from the list, including `.md`).\n\n- **CallTool** with tool name **`get_guide`** and arguments **`{\"guide_name\": \"guide_name.md\"}`** \n Example: call tool **`get_guide`** with **`{\"guide_name\": \"python.md\"}`**.\n\nBoth return the full markdown content of the guide. Use one or the other; no need to use both for the same guide.\n\n### Step 3: Follow references (MANDATORY)\n\nGuides are deliberately small: they do **not** duplicate shared content. Instead they **reference** other guides that own a cross-cutting concern (TDD, hexagonal architecture, secure coding, error handling, logging, configuration, etc.). You **MUST** follow those references — a guide is incomplete without them.\n\nWhen a guide you fetched contains a reference marker, act on it:\n\n- **📎 REQUIRED** — You **MUST** fetch and apply the linked guide **before writing any code**. It is a hard prerequisite; the referencing guide assumes its rules and does not restate them. Skipping it means you are violating mandatory standards.\n- **📎 RECOMMENDED** — You **MUST** fetch and apply the linked guide **if the current task touches that concern** (e.g. fetch `logging.md` when the task involves logging).\n- **📎 SEE ALSO** — Optional; fetch for additional depth when useful.\n\nReference targets appear as `guides://<name>.md` links (e.g. `guides://tdd.md`). Resolve each one with **ReadResource** or the **`get_guide`** tool, exactly as in Step 2. Follow references **transitively** — if a referenced guide has its own REQUIRED references, fetch those too. Fetch each guide only once per task and reuse it.\n\nA guide's machine-readable prerequisites are also listed in its YAML frontmatter under `requires:` (must fetch) and `recommends:` (fetch when relevant); the `name` values map to `<name>.md`. Use these to plan which guides to pull up front.\n\n### Step 4: Apply the guidelines\n\nFollow the fetched guidelines — and every guide they REQUIRED/RECOMMENDED you to fetch — as mandatory standards when writing, reviewing, or modifying code. If multiple guides apply, follow all of them. Each guide also contains an auditable requirements table (IDs like `PY-TST-01`) with verification commands and pass/fail gates: satisfy every gate before presenting code. Treat the guides like project AGENTS.md or Skills.\n\n---\n\n## API Reference\n\n### Resources\n\n| URI | Description |\n|-----|-------------|\n| **`guides://list`** | Single resource. Read it to get a plain-text list of all guides. Each line: **`guides://guide_name.md - brief description`**. The first token is the resource URI you can pass to ReadResource. |\n| **`guides://{guide_name}`** | Resource template. Read a specific guide by URI, e.g. **`guides://python.md`**, **`guides://rest.md`**. Use the exact URI from the list (first token of each line). |\n\n- Use **ReadResource** with the URI to get content. The list from `guides://list` returns full URIs (e.g. `guides://python.md`) so you can use each line’s first token directly as the ReadResource URI.\n- Guide names/URIs must be exact (e.g. `guides://python.md` not `Python.md`). No path segments: only a single filename in the URI, like `guides://docker-compose.md`.\n\n### Tools\n\n| Name | Description | Arguments |\n|------|-------------|-----------|\n| **`get_guide`** | Returns the full content of a specific coding guide. | **`guide_name`** (string, required): exact filename (e.g. `\"python.md\"`) or full URI (e.g. `\"guides://python.md\"`). Either form is accepted. |\n\n- Use **CallTool** with name **`get_guide`** and arguments **`{\"guide_name\": \"guides://python.md\"}`** or **`{\"guide_name\": \"python.md\"}`**.\n\n---\n\n## List output format (`guides://list`)\n\nThe list is plain text, one guide per line:\n\n```\nguides://guide_name.md - brief description extracted from the guide\n```\n\n- **guides://guide_name.md**: full resource URI. Use this string as the URI for **ReadResource** to fetch the guide, or pass it (or just `guide_name.md`) to the **get_guide** tool.\n- **brief description**: short summary (up to ~250 characters) of what the guide covers.\n\n---\n\n## Error handling\n\n- **Guide not found**: Use the exact name from `guides://list` (including `.md`). Names are case-sensitive.\n- **Invalid guide name**: Do not use path segments, backslashes, or `..`. Use only a single filename, e.g. `python.md`.\n- **Empty list from `guides://list`**: The server may be offline or unable to reach the guide source. Retry later or proceed with general best practices.\n- **Multiple guides**: Fetch each guide separately (one ReadResource or one CallTool per guide).\n",
"tools": [
{
"description": "Get the content of a specific coding guide.",
"inputSchema": {
"properties": {
"guide_name": {
"title": "Guide Name",
"type": "string"
}
},
"required": [
"guide_name"
],
"title": "get_guideArguments",
"type": "object"
},
"name": "get_guide",
"outputSchema": {
"properties": {
"result": {
"title": "Result",
"type": "string"
}
},
"required": [
"result"
],
"title": "get_guideOutput",
"type": "object"
}
}
]
}Verify it yourself
curl -s https://api.teppi.xyz/v1/evidence/sha256:e82c110a99da7b9be3fc8575c1ae5ef63b0776f236f4835ab79b995d4d1881b6 | sha256sum