What can you do with this server?

aik-mcp turns a directory of Markdown files with YAML frontmatter into a live, queryable knowledge base served over the Model Context Protocol (MCP), letting AI agents discover, read, search, and manage reusable rules, skills, workflows, agents, commands, and templates at runtime. * List content (list): Browse available knowledge items with optional filtering by category, tag, or text query. * Retrieve content (get): Fetch a specific knowledge item by its path (e.g. rules/typescript). * Search content (search): Perform full-text fuzzy search across all content, with optional category filtering and result limits. * Write content (write): Create or update a knowledge item with a Markdown body and YAML frontmatter (title, description, tags), with an overwrite option. * Delete content (delete): Remove a knowledge item by its path. * Install content (install): Push a knowledge item into the current project's AI agent config (opencode, Claude Code, or Cline) for automatic loading in future sessions. * Reinstall content (reinstall): Uninstall and re-install the latest version of a previously installed item. * Uninstall content (uninstall): Remove a specific installed item from the project config. * Uninstall all (uninstall_all): Remove all aik-managed items from the project config at once. * List installed (list_installed): See which knowledge items are currently installed in the project's agent config. * Check for updates (check_updates): Identify installed items that have newer versions available in the knowledge base. * Update content (update): Update a specific installed item to its latest version. The server also provides live file-system synchronization, so the in-memory cache updates instantly when files change.

How do I use aik-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aik-mcp search for typescript conventions" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

aik-mcp

by openhoat

Overview Schema Related Servers Score Discussions

TypeScript

Local

aik-mcp turns a directory of Markdown files into a live, queryable knowledge base for any MCP-compatible AI agent — opencode, Claude Code, Cline, Codex, GitHub Copilot, and more.

Write your team's conventions, reusable workflows, agent prompts, and project templates as plain .md files with YAML frontmatter. aik-mcp serves them on demand — your agent can discover, read, search, and install them at runtime, across any project.

No database. No API to build. Just Markdown.

Features

Icon	Feature	Why it matters
📝	Knowledge as Markdown	Plain `.md` files with frontmatter. Version them with git. Review them in PRs.
⚡	Zero config	`npx aik-mcp` runs immediately. Point it at a folder of Markdown files. Done.
🔎	Full-text search	Fuzzy search across every rule, skill, and template — powered by Fuse.js.
📦	Install on demand	Push knowledge directly into your agent's runtime config with a single tool call.
👀	Live sync	A file watcher detects changes instantly. No restart. No downtime.
🔌	Universal MCP	Works with opencode, Claude Code, Cline, Codex, Copilot, and any MCP-compatible client.

Related MCP server: Function Concept MCP

Quick start

1. Create a rule

mkdir -p my-knowledge/rules
cat > my-knowledge/rules/typescript.md << 'EOF'
---
title: TypeScript Conventions
description: Coding standards for TypeScript projects
tags: [typescript, conventions]
version: "1.0.0"
compatibility: [opencode, claude-code, cline, codex, copilot]
---

## TypeScript Conventions

- Use explicit types for public API surfaces
- Prefer `interface` over `type` for object shapes
- Use `const` assertions for literal values
EOF

2. Start the server

AIK_CONTENT_DIR=./my-knowledge npx aik-mcp

3. Ask your agent

"Find and apply the TypeScript conventions rule for this project."

Your agent calls aik_search, reads the rule, and applies it — all transparently through MCP.

Docs

Full documentation is available at openhoat.github.io/aik-mcp.

How it works

graph LR
    Agent[AI Agent<br>opencode / Claude Code / Cline / Codex / Copilot] -->|MCP JSON-RPC| Server(aik-mcp)
    Server --> Store[Content Store<br>in memory]
    Store --> Files[Markdown files<br>rules/ skills/ workflows/ ...]
    Server --> Watcher[File Watcher<br>live sync on change]
    Server --> Tools[MCP Tools<br>list, get, search, write,<br>install, uninstall]

Your agent speaks MCP on one side. aik-mcp speaks your file system on the other. Everything is cached in memory for fast lookups, and a file watcher keeps the cache up to date.

Client configuration

opencode

Add to opencode.jsonc or .opencode/opencode.jsonc in your project:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "aik": {
      "type": "local",
      "command": ["npx", "-y", "aik-mcp"],
      "enabled": true,
      "environment": {
        "AIK_CONTENT_DIR": "/path/to/your/knowledge",
        "LOG_LEVEL": "info"
      }
    }
  }
}

Claude Code

Add to .mcp.json or ~/.claude/settings.json:

{
  "mcpServers": {
    "aik": {
      "command": "npx",
      "args": ["aik-mcp"],
      "env": {
        "AIK_CONTENT_DIR": "/path/to/your/knowledge",
        "LOG_LEVEL": "info"
      }
    }
  }
}

Cline

Add to cline.json or project .mcp.json:

{
  "mcpServers": {
    "aik": {
      "command": "npx",
      "args": ["aik-mcp"],
      "env": {
        "AIK_CONTENT_DIR": "/path/to/your/knowledge",
        "LOG_LEVEL": "info"
      }
    }
  }
}

Codex

Add to ~/.codex/config.toml or project .codex/config.toml:

[mcp]
"aik" = { command = ["npx", "aik-mcp"], env = { AIK_CONTENT_DIR = "/path/to/your/knowledge", LOG_LEVEL = "info" } }

GitHub Copilot

Configure the MCP server in your IDE settings (VS Code, JetBrains, etc.) and add project instructions to .github/copilot-instructions.md:

## MCP servers

aik-mcp provides knowledge management. Use `aik_list`, `aik_get`, `aik_search`, `aik_install`, and related tools to manage rules, skills, workflows, and templates.

Tip: Set AIK_CONTENT_DIR to a shared path (Dropbox, git repo, team NAS, etc.) to use the same knowledge base across projects and agents.

Content structure

Content items are organized by category:

Directory	Purpose
`rules/`	Coding standards, conventions, quality gates
`skills/`	Reusable instruction blocks (prompts, recipes)
`workflows/`	Multi-step process definitions
`agents/`	Specialized agent configurations
`commands/`	Custom CLI command definitions
`templates/`	File and project scaffolding

Each file is a Markdown document with YAML frontmatter:

---
title: "My Rule"
description: "What this rule enforces"
tags: [tag1, tag2]
version: "1.0.0"
compatibility: [opencode, claude-code, cline, codex, copilot]
---

## My Rule

Content here...

MCP tools

Tool	Description
`aik_list`	List content items, optionally filtered by category or tag
`aik_get`	Retrieve a specific item by path (e.g. `rules/typescript`)
`aik_search`	Full-text fuzzy search across all content
`aik_write`	Create or update a content item from the agent
`aik_delete`	Delete a content item
`aik_install`	Install an item into the project's agent config
`aik_reinstall`	Reinstall the latest version of an installed item
`aik_uninstall`	Remove an installed item from the project
`aik_uninstall_all`	Remove all aik-installed items from the project
`aik_list_installed`	List items currently installed in the project

Resources

URI	Description
`aik://{category}`	List all items in a category (e.g. `aik://rules`)
`aik://search?q=...`	Search items by keyword

CLI options

Flag	Default	Description
`--http`	—	Start in HTTP/SSE mode instead of stdio
`--port <n>`	`3456`	HTTP server port (only with `--http`)
`--no-watch`	—	Disable file watching

Environment variables

Variable	Default	Description
`AIK_CONTENT_DIR`	`.`	Path to the content directory
`LOG_LEVEL`	`info`	Log level: `trace`, `debug`, `info`, `warn`, `error`, `silent`

Development

npm install
npm run build
npm run test
npm run qa

Scripts

Script	Description
`npm run build`	Compile TypeScript to `build/`
`npm test`	Run Vitest test suite
`npm run qa`	Lint + format check (Biome + markdownlint)
`npm run qa:fix`	Auto-fix lint and formatting issues
`npm run typecheck`	TypeScript type checking (`tsc --noEmit`)
`npm run validate`	Full pipeline: qa → typecheck → build → test

Contributing

Contributions are welcome! Open an issue or submit a PR.

See the changelog for release history.

Full documentation at openhoat.github.io/aik-mcp.

License

MIT

Available Tools

12 tools

check_updatesB

Check for installed content items that have newer versions available in the knowledge base.

ParametersJSON Schema

Name	Required	Description	Default
`agent`	Yes	Target AI agent (opencode, claude-code, cline, codex, or copilot).
`projectDir`	No	Project directory (defaults to current working directory). Config files are found by walking up.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic function without mentioning side effects, required permissions, rate limits, or response format. The read-only nature is implied but not explicit.

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 a single concise sentence that is front-loaded with the action. No extraneous words. It could be slightly improved with additional context, but it remains efficient.

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 checks for updates, the description omits critical context: what the tool returns (e.g., list of items or boolean), whether it is safe to call repeatedly, and that it does not modify anything. Without an output schema, the description should provide hints about the return value. It is incomplete for decision-making.

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%, so the baseline is 3. The description does not add any parameter-specific information—it only repeats the general purpose. The schema already sufficiently documents both parameters, including the enum values for 'agent' and the optional nature of 'projectDir'.

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's purpose: to check for installed content items with newer versions available. It uses specific verbs ('check', 'have newer versions') and identifies the resource ('installed content items', 'knowledge base'). This distinguishes it from sibling tools like 'update' which likely perform the actual update.

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 does not provide guidance on when to use this tool versus alternatives. It does not mention prerequisites, recommended scenarios, or when to use related tools like 'update' or 'list'. The agent receives no context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deleteB

Delete a content item by its path

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the content item to delete (e.g. "rules/coding-standards")

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Merely states 'Delete' without disclosing irreversibility, safety, or confirmation requirements.

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?

Single sentence, no waste, but could benefit from additional behavioral context without losing conciseness.

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?

Minimal viable for a simple delete tool, but missing return value, error handling, and behavioral caveats given no output schema or 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 has 100% coverage with parameter description for 'path'. Tool description adds no extra meaning beyond what schema already provides.

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 states 'Delete a content item by its path', using a specific verb ('delete') and resource ('content item'), clearly distinguishing from sibling tools like 'uninstall' (packages).

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?

Implies when to use (deleting content items by path), but no explicit guidance on when not to use or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getA

Retrieve a specific content item by its path (e.g. "rules/coding-standards")

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the content item (e.g. "rules/coding-standards")

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states 'Retrieve', implying a read-only operation. It lacks disclosure of behavioral traits such as error handling, return format, or edge cases, though the simplicity of a 'get' tool makes the description minimally 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?

The description is a single, front-loaded sentence with no superfluous words. Every word is necessary to convey the action and parameter, making it highly concise.

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 tools with one parameter and no output schema, the description explains the action and parameter usage well. It is mostly complete but could enhance by specifying return value format or common error scenarios.

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 the schema already documents the 'path' parameter. The description adds an example ('rules/coding-standards') but does not provide additional semantic depth beyond what the schema offers.

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 uses a specific verb 'Retrieve' and resource 'content item', with clear method 'by its path'. It effectively distinguishes from siblings like 'delete', 'update', and 'search', 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 Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus alternatives (e.g., 'search' for unknown paths). There is no mention of prerequisites or exclusions, 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.

installA

Install a content item (rule, skill, workflow, agent, command, or template) into the current project so it is loaded automatically in future sessions. Supports opencode, Claude Code, Cline, and Codex.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path of the content to install (e.g. "rules/typescript")
`agent`	Yes	Target AI agent (opencode, claude-code, cline, codex, or copilot).
`projectDir`	No	Project directory (defaults to current working directory). Config files are found by walking up.

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions installation makes content persistent but lacks details on side effects (e.g., overwriting existing items), permission requirements, or error behavior. There is a minor inconsistency: description lists four agents but schema includes 'copilot', which could mislead.

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-loads the verb and resource, and contains no extraneous information. Every word earns its place.

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?

Given three parameters and no output schema, the description covers core purpose but lacks depth on behavioral traits like overwrite behavior, error handling, or confirmation steps. It is adequate but not complete for a tool that modifies the project.

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 adds no additional parameter details beyond the schema's descriptions. It does not enhance understanding of parameter usage beyond what the schema already provides.

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 installs a content item into the current project, lists specific content types, and explains the benefit of automatic loading in future sessions. It distinguishes from siblings like 'uninstall' and 'delete' by focusing on installation.

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 making content persistent across sessions but does not explicitly state when to use this tool versus alternatives like 'update' or 'reinstall'. No exclusion criteria or 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.

listC

List available content items (rules, skills, workflows, agents, commands, templates)

ParametersJSON Schema

Name	Required	Description
`tag`	No	Filter by tag
`query`	No	Filter by text query in title/description
`category`	No	Filter by content category

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only says 'list available content items'. No mention of behavior like pagination, sorting, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, no fluff. Could be improved by adding brief usage context without sacrificing conciseness.

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?

No output schema, 3 optional parameters, yet description is minimal. Does not explain what 'available' means (e.g., local vs remote) or how results are structured.

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%, so parameters are described in the schema. The description adds no extra meaning beyond the schema, maintaining 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 states 'List available content items' and enumerates item types, making the verb and resource clear. However, it does not explicitly differentiate from sibling tools like 'list_installed' or 'search'.

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 (e.g., search, list_installed). Lacks any context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_installedB

List all aik-installed content items in the current project config. Supports opencode, Claude Code, Cline, and Codex.

ParametersJSON Schema

Name	Required	Description	Default
`agent`	Yes	Target AI agent (opencode, claude-code, cline, codex, or copilot).
`projectDir`	No	Project directory (defaults to current working directory). Config files are found by walking up.

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must disclose behavioral traits. It neither mentions that the operation is read-only nor any side effects, permissions, or limitations. This omission is significant for a mutation-ambiguous tool.

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 short sentences that convey core purpose and context. No wasted words, but the list of supported agents could be integrated more efficiently.

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?

Given no output schema, the description could explain return format. The tool is low complexity and parameters are clear, but lack of behavioral context and output expectations reduces completeness.

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%, so the baseline is 3. The description adds no extra semantics for parameters; it mentions supported agents (missing 'copilot' from schema), but doesn't enhance understanding beyond the schema's own descriptions.

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 verb 'List' and the resource 'aik-installed content items' scoped to 'current project config'. This sufficiently identifies the tool's function, though it could more explicitly differentiate from the sibling tool 'list'.

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?

Usage context is implied: list installed items in project config. It mentions supported agents but no guidance on when to use this vs sibling tools like 'list' or 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.

reinstallB

Reinstall a previously installed content item. Uninstalls the old entry and installs the latest version from the knowledge base. Supports opencode, Claude Code, Cline, and Codex.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path of the content to reinstall (e.g. "rules/typescript")
`agent`	Yes	Target AI agent (opencode, claude-code, cline, codex, or copilot).
`projectDir`	No	Project directory (defaults to current working directory). Config files are found by walking up.	/app

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It mentions uninstalling old and installing latest, but lacks details on side effects, idempotency, error handling, or prerequisites (e.g., item must be previously installed).

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 clear action and supported agents. No redundant information, though it could be more structured with bullet points for supported agents.

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?

Given no annotations and no output schema, the description is adequate but lacks details about return values, error conditions, and the behavior of the projectDir parameter. It covers the core action but leaves gaps.

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%; all parameters have descriptions in the schema. The description adds minimal value beyond listing supported agents, which overlaps with the enum in 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 clearly states the tool reinstalls a previously installed content item by uninstalling the old entry and installing the latest version. It names the supported agents, distinguishing it from siblings like install, uninstall, and update.

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 reinstallation after initial install but provides no explicit guidance on when to use this tool over alternatives like install, update, or uninstall.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchB

Full-text fuzzy search across all content items

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum results
`query`	Yes	Search query
`category`	No	Restrict search to a category (rules, skills, workflows, agents, commands, templates)

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. While 'fuzzy' hints at approximate matching, it omits details about sorting, pagination, result format, performance implications, or side effects such as whether it performs a destructive operation.

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 a single efficient sentence with no wasted words. However, it could add a bit more detail (e.g., result format) without becoming overly long.

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 3 parameters and no output schema, the description is too terse. It lacks return value information, result structure, and any limitations. For a search tool with numerous siblings, more context is needed for the agent to invoke it correctly.

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 mentions 'fuzzy' which adds nuance to the query parameter but does not define it (e.g., stemming, typos). For 'limit' and 'category', the description adds no extra 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 clearly states the action ('search'), the target resource ('all content items'), and specifies the type ('full-text fuzzy'), which distinguishes it from sibling tools like 'list' (for listing all) and 'get' (for retrieving a specific item).

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 does not provide any guidance on when to use this tool versus alternatives like 'list' or 'get'. There are no explicit when-to-use or when-not-to-use statements, leaving the agent to infer context 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.

uninstallA

Uninstall a content item from the current project. Removes the file and the config reference. Supports opencode, Claude Code, Cline, and Codex.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path of the content to uninstall (e.g. "rules/typescript")
`agent`	Yes	Target AI agent (opencode, claude-code, cline, codex, or copilot).
`projectDir`	No	Project directory (defaults to current working directory). Config files are found by walking up.

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses destructive behavior (removes file and config reference) but does not mention reversibility, permissions, or side effects on other items.

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 clearly convey purpose and effect with no unnecessary words. Efficient and focused.

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 core purpose and destruction effect, but lacks usage context, parameter nuances (e.g., path format), and output expectations. Acceptable but not rich.

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%, so schema already describes parameters. Description adds no additional meaning beyond the schema beyond the general effect. Baseline 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?

Description clearly states the action (uninstall), the resource (content item), and the effect (removes file and config reference). This distinguishes it from sibling tools like install, delete, and uninstall_all.

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 (e.g., delete, uninstall_all). Does not mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

uninstall_allA

Uninstall ALL aik-installed content items from the current project. Removes all aik-managed files and config references.

ParametersJSON Schema

Name	Required	Description	Default
`agent`	Yes	Target AI agent (opencode, claude-code, cline, codex, or copilot).
`projectDir`	No	Project directory (defaults to current working directory). Config files are found by walking up.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description alone must disclose behavioral traits. It mentions removing files and config references, which suggests destructive behavior, but lacks details on reversibility, required permissions, or side effects (e.g., project state changes). Adequate but not rich.

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, each earning its place: the first states the core action, the second adds the details about what gets removed. No redundant or filler content.

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 there is no output schema, the description does not explain return values, which is acceptable for a destructive action. It covers the key aspects: scope (current project), target (all aik-managed files/config), and agent parameter. Could mention prerequisites or confirmation steps, but fairly complete for a focused tool.

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 100% coverage with descriptions for both parameters (agent and projectDir). The description adds no extra meaning beyond these schema descriptions, aligning with the baseline score of 3 when schema coverage is high.

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 verb 'Uninstall', the resource 'aik-installed content items', and the scope 'ALL' and 'from the current project'. This distinguishes it from sibling tools like 'uninstall' (likely single item) through the explicit 'ALL' qualifier.

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 clarifies that it operates on the 'current project' and removes 'all aik-managed files and config references', providing clear context. However, it does not explicitly state when not to use this tool or provide alternatives (e.g., for selective uninstall), though ALONE it implies a bulk operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

updateA

Update a previously installed content item if a newer version is available in the knowledge base. Supports opencode, Claude Code, and Cline.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path of the content to update (e.g. "rules/typescript")
`agent`	Yes	Target AI agent (opencode, claude-code, cline, codex, or copilot).
`projectDir`	No	Project directory (defaults to current working directory). Config files are found by walking up.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that update only occurs when newer version exists and specifies supported agents. Does not detail what happens if no update available or permissions needed, but given tool's simplicity, 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 sentences, no fluff. First sentence states core purpose and condition, second lists supported agents. Information-dense and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters with full schema descriptions and no output schema, description covers the key behavior and condition. Lacks error handling or return value info, but tool is straightforward. Mostly complete for its complexity.

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. Description adds little beyond schema: mentions three agents but schema includes five. No additional context on parameter semantics.

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 it updates previously installed items if a newer version exists. Verb 'update' with resource 'content item' and condition 'if newer version available' makes purpose very specific. Distinguishes from siblings like install (new) and reinstall (forced reinstall).

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 provides condition for use ('if newer version is available') and lists supported agents (opencode, Claude Code, Cline). However, it doesn't explicitly exclude use cases or mention alternatives like check_updates or reinstall. Still gives enough context for when to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

writeB

Create or update a content item (rules, skills, workflows, agents, commands, templates)

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path for the content (e.g. "rules/coding-standards"). Category is derived from the first path segment.
`tags`	No	Tags (frontmatter)
`title`	No	Title (frontmatter)
`content`	Yes	Markdown body content (without frontmatter)
`overwrite`	No	Set to true to overwrite an existing file
`description`	No	Short description (frontmatter)

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior. It notes path derives category, which is useful, but lacks details on authentication, reversibility, or side effects beyond 'overwrite' parameter.

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?

Single sentence, front-loaded with action and resource types, no filler. Extremely concise yet informative.

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?

No output schema; description does not mention return values or errors. However, for a mutation tool, this is acceptable but could be improved.

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 covers all 6 parameters (100% coverage), so baseline is 3. Description adds only that category derives from path segment, slightly enhancing understanding.

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 creates or updates content items and lists examples (rules, skills, etc.). However, it does not differentiate from the sibling 'update' tool, which may cause confusion.

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 'update' or 'create'. No prerequisites or exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing vs. searching vs. getting a single item, installing vs. updating vs. uninstalling. No two tools have overlapping functionality.

Naming Consistency5/5

All tools use lowercase imperative verbs with underscores (e.g., check_updates, list_installed, uninstall_all). The naming pattern is uniform and predictable.

Tool Count5/5

With 12 tools, the server is well-scoped for managing content items (rules, skills, etc.). It covers all necessary operations without being bloated or insufficient.

Completeness5/5

The tool set provides full lifecycle management: create (write), read (get, list, search), update (update, write), delete (delete, uninstall, uninstall_all), and maintenance (check_updates, reinstall). No obvious gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AgentPlaybooks A
ai.agentplaybooks
Manage portable AI agent playbooks, Agent Skills, MCP configurations, personas, and memory.
Autonomous Agents Knowledge & Memory
4914
iknow
dev.iknow
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Knowledge & Memory Search Documentation Access
1
Sharebench A
ai.sharebench
Sharebench — search & pull AI skills, agents, prompts & playbooks (SKILL.md) into any MCP client
AI & Machine Learning Developer Tools Search
22
Knowledge Raven
com.knowledge-raven
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.
RAG Systems Knowledge & Memory Search
2

Related MCP Servers

MinerU Document Explorerofficial
RAG Systems Search
opendatalab
A
license
Not graded
quality
D
maintenance
Enables AI agents to search, deep-read, and build knowledge bases from Markdown, PDF, DOCX, and PPTX documents via MCP tools for retrieval, document navigation, and ingestion.
Updated 4 months ago (2026-04-26 07:10 UTC)
50
627
MIT
Function Concept MCP
Knowledge & Memory Documentation Access
blackmarketing2026
F
license
Not graded
quality
C
maintenance
Enables access to a local Markdown knowledge base via MCP, currently only providing a ping tool.
Updated a month ago (2026-07-30 07:23 UTC)
skilltap
Documentation Access File Systems Developer Tools
yulinlina
A
license
Not graded
quality
C
maintenance
Exposes MCP tools to list, search, and load Markdown skills from a local folder, enabling coding agents to discover and reuse procedural knowledge.
Updated 21 days ago (2026-08-13 16:40 UTC)
MIT
agent-memory
Knowledge & Memory File Systems Developer Tools
Lolaplex
F
license
Not graded
quality
B
maintenance
Provides a local markdown-based memory system for coding agents through MCP, enabling search, add, register, inventory, sync, and ingest operations across user and project memory. It gives any agent tool a durable, provider-agnostic shared memory stored in folders you own.
Updated 15 days ago (2026-08-19 16:09 UTC)
2

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/openhoat/aik-mcp'

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

Features

Quick start

1. Create a rule

2. Start the server

3. Ask your agent

Docs

How it works

Client configuration

opencode

Claude Code

Cline

Codex

GitHub Copilot

Content structure

MCP tools

Resources

CLI options

Environment variables

Development

Scripts

Contributing

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

MinerU Document Explorerofficial

Latest Blog Posts

MCP directory API