The ak-mcp server provides queryable documentation, API details, and guidance for the AK (Active Kernel) event-driven MCU framework, helping AI tools generate correct firmware code. Key capabilities include:
Search AK Docs (search_ak_docs): Full-text BM25 search across AK concepts, guides, guardrails, and API entries, with optional filtering by section (api, concept, guide, guardrail).
Get AK API Entry (get_ak_api): Retrieve exact signatures, parameters, return values, semantics, usage examples, and FATAL error codes for specific AK kernel functions, macros, or types (e.g., timer_set, task_post_pure_msg).
List AK API (list_ak_api): Browse all AK kernel API symbols with one-line summaries, optionally filtered by module (task, message, timer, fsm, tsm, ak, port).
Get AK How-To Guide (get_ak_guide): Step-by-step recipes with skeleton code and wiring instructions for common tasks like create-task, create-driver, create-screen, isr-bridge, tune-pools, and use-timer.
Get AK Guardrails (get_ak_guardrails): Mandatory rules and kernel invariants for AK development (e.g., no blocking, fixed pools, 64-byte payload, max 7 refs, priority 0 reserved) — essential before generating any code.
Start New AK Projects: Resolve the latest base-kit release and get setup commands and a customization plan.
Analyze AK Debug Logs: Process raw UART output to get structured diagnoses for FATAL errors, timing problems, or reboot loops.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ak-mcp show me the API signature for ak_timer_start"
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.
| EN | VN |
A free, public Model Context Protocol server that gives AI coding tools accurate, queryable knowledge base for the AK (Active Kernel) event-driven MCU framework (firmware: ak-base-kit-stm32l151).
It lets an AI assistant:
Understand the AK kernel core (scheduler, message pools, timers, FSM/TSM),
Look up exact API signatures and arguments (extracted straight from the headers, so they never drift),
Follow the rules & format for creating tasks, drivers, and screens,
Design new tasks/drivers without touching the kernel, boot, sys, networks, or common code.
(*) Deeply understanding your product is the root of automation success !
This repo is standalone - the kernel headers are vendored (committed) under
vendor/ak-inc/, so nothing else needs to be cloned to build it.
vendor/ak-inc/*.h ──────────────► scripts/extract.mjs ─┐ (snapshot of the kernel
▲ refreshed by │ headers; refresh with
scripts/fetch-headers.mjs (GitHub) ├─► npm run fetch-headers)
corpus/ (hand-written guides, scripts/build-corpus ┘─► generated/corpus.json
guardrails, enrichment) ───────────────────────────► (docs + BM25 index)
│
src/core (resources + tools + prompts)
├── src/worker -> Cloudflare Worker (remote HTTP)
└── src/cli -> npx ak-mcp (stdio, local)Signatures come from the vendored kernel headers; semantics/examples are layered on per symbol (corpus/enrichment/). A CI drift check fails if any cross-reference points at a symbol the headers no longer define.
Related MCP server: AI Development Guidelines MCP Server
Tools
Tool | Purpose |
| resolve the latest base-kit release and return download/extract commands + a customization plan |
| BM25 search across everything |
| exact signature, params, returns, semantics, examples, FATAL codes |
| browse the API by module (task/message/timer/fsm/tsm/ak/port) |
| recipes: start-project, create-task, create-driver, create-screen, use-timer, isr-bridge, tune-pools, debug-uart-shell, kernel-task-log, agent-workflow |
| do-not-modify zones + kernel invariants |
| paste raw UART output -> structured diagnosis: FATAL cause/fix, timing (run-to-completion/starvation), reboot loops, next shell commands |
| paste a |
Prompts: ak-new-project, ak-new-task, ak-new-driver, ak-debug - guided scaffolding/debugging that enforces conventions and guardrails.
Debugging loop: the board's only debug surface is its 115200 UART console (leveled printf
an interactive shell). Agents capture it non-interactively with
examples/ak-console.py (pyserial; destructive shell commands are
blocked unless --allow-destructive), then feed the text to analyze_ak_log.
Resources: ak://index, and ak://{section}/{id} for every concept, guide, guardrail, and API entry.
The build reads the AK kernel's public headers, which are committed under vendor/ak-inc/
(a snapshot of a firmware release tag - see vendor/ak-inc/SOURCE.txt). Cloning this repo is
enough to build it: no firmware checkout required.
Refresh the snapshot when the kernel changes:
npm run fetch-headers # pinned default tag (v1.3)
npm run fetch-headers v1.4 # a specific release tagthen npm run build:corpus and commit vendor/ak-inc/. Header resolution order (first
existing wins) - override only if you want to build against a live firmware checkout:
$AK_INC_DIR - exact path to .../application/sources/ak/inc
$AK_FIRMWARE_DIR/application/sources/ak/inc - a firmware repo root
vendor/ak-inc/ - the committed snapshot (default)
Once generated/corpus.json is built, the running server (stdio or Worker) needs nothing
external - the corpus is self-contained.
npm install
npm run build:corpus # generate generated/corpus.json from the headers + corpus/
npm run drift # build + fail on broken cross-references
npm test # extractor, corpus integrity, and search ranking (no deps needed)
npm run typecheck # core + cliThe corpus pipeline (scripts/*.mjs) and tests are zero-dependency and run on plain Node ≥ 20 - no install required for npm run build:corpus / node --test (only the firmware headers must be reachable as above).
npm run build # build:corpus + tsc -> dist/
node dist/cli/bin.js # or, after publishing: npx -y ak-mcpInspect it with the MCP Inspector:
npx @modelcontextprotocol/inspector node dist/cli/bin.jsClient config (Claude Desktop / Cursor):
{ "mcpServers": { "ak": { "command": "npx", "args": ["-y", "ak-mcp"] } } }The Worker bundles corpus.json at build time, so it needs no database.
npm run dev # local Streamable HTTP at http://localhost:8787/mcp
npm run deploy # build:corpus + wrangler deployEndpoints: /mcp (Streamable HTTP), /sse (legacy), / (landing page).
Remote client config:
{ "mcpServers": { "ak": { "url": "https://ak-mcp.<your-account>.workers.dev/mcp" } } }Using it in VS Code (vibe coding): see docs/vscode-vibe-coding.md
for step-by-step setup (Copilot Agent mode, Cursor, Cline, Claude Code), a copy-paste
.vscode/mcp.json template, and a project steering file
(examples/copilot-instructions.md).
CI (.github/workflows/ak-mcp.yml) builds from the vendored headers (no firmware checkout):
verify runs build + drift + tests + typecheck on every change, and deploy ships from main
when CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID secrets are set. A refresh-headers job
(manual Run workflow with an optional tag, or a repository_dispatch of type
firmware-updated from the firmware repo) re-fetches vendor/ak-inc/, verifies it, and commits
the update if anything changed.
The kernel released a new version? Run npm run fetch-headers [<tag>] to refresh vendor/ak-inc/, then npm run build:corpus and commit the snapshot. New/changed signatures are then extracted automatically.
A new API needs prose? Add corpus/enrichment/<symbol>.md to give it semantics/examples (the signature is already extracted).
A new recipe or concept? Add a markdown file under corpus/guides/ or corpus/concepts/ with frontmatter (id, title, tags, summary, optional apis).
Run npm run drift to verify all references resolve.
Enrichment / content frontmatter:
---
symbol: timer_set # enrichment only
summary: One-line summary.
fatal_codes: MT:0x30
see_also: timer_remove_attr, timer_tick
tags: timer, periodic
---
Markdown body (semantics, examples) ...Paste raw UART console output from an AK board (boot logs, -SIG-> traces, FATAL banners, fatal l/fatal m dumps, timing lines) and get a structured diagnosis: detected FATAL codes with cause and fix, run-to-completion/starvation timing issues, reboot-loop detection, and the exact shell commands to run next.
| Name | Required | Description | Default |
|---|---|---|---|
| log | Yes | Raw text captured from the 115200 UART console. | |
| context | No | Optional: what the engineer observed (symptom, when it happens). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It describes the input format and expected outputs (FATAL codes, timing analysis, reboot detection, shell commands). It does not mention side effects or permissions, which is acceptable for a read-only diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the purpose. Every part contributes meaning (input, types of analysis, output), with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's diagnostic role and lack of output schema, the description fully covers inputs and outputs. It explains what the tool does with the log and what structured diagnosis it returns, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying the types of content expected (boot logs, -SIG-> traces, FATAL banners) and what the output includes, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'analyze' and resource 'AK UART log', listing concrete outputs (FATAL codes, timing issues, reboot-loop, shell commands). It clearly distinguishes from sibling tools like search_ak_docs or get_ak_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool (when you have raw UART console output) and what it does. It does not explicitly exclude alternatives, but the context is clear enough that this tool is for log diagnosis, while siblings serve other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See the board's OLED screen headlessly: paste the raw output of the shell command lcd d (the 0xNN,0xNN,... framebuffer dump) and get the screen rendered as text art plus a PNG image, with content stats. Format: 128x64 @ 1bpp, page-major, LSB = top pixel (Adafruit_oled_drv).
| Name | Required | Description | Default |
|---|---|---|---|
| dump | Yes | Raw `lcd d` capture, including the 0xNN,... lines. | |
| scale | No | PNG upscale factor (default 4 → 512×256). | |
| invert | No | Set true if the display is inverted (content drawn dark on light). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the input format, the rendering process (text art + PNG), and mentions content stats. It does not disclose any side effects but for a decode tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and includes all necessary information. It is front-loaded with the main action. Could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description fully covers what the tool does and what the user should expect (text art + PNG + stats). For a simple decode tool with clear input requirements, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds extra context: explains the expected dump format, default scale of 4, and the meaning of invert in terms of dark/light display behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Decode AK OLED framebuffer' and details the output (text art + PNG) with format specs. It is clearly different from sibling tools which deal with docs, APIs, and logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs users to paste the raw output of shell command 'lcd d', giving clear context for when to use. It does not list alternatives but sibling tools are unrelated, so the usage scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact signature, parameters, return value, semantics, examples, and FATAL codes for an AK kernel function, macro, or type (e.g. 'timer_set', 'task_post_pure_msg').
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | The exact symbol name, e.g. 'timer_set'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes exactly what the tool provides (signature, parameters, return value, etc.) and gives an example. With no annotations, it carries the full burden; it clearly indicates a read-only lookup without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the list of outputs, includes an example. Every word is valuable and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool without output schema, the description covers the expected return items comprehensively. It lacks details on result format or error handling, but the provided list is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds example symbol names but no additional semantics beyond the schema's 'exact symbol name'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns exact signature, parameters, return value, semantics, examples, and FATAL codes for an AK symbol. It uniquely distinguishes from siblings like list_ak_api and search_ak_docs by focusing on detailed documentation for a specific symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings. It doesn't mention that it is best when the exact symbol is known or when detailed info is needed, nor does it exclude cases where search or list would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rules every AK contribution must follow: which directories are off-limits (kernel, boot, networks, common) and the kernel invariants (no blocking, fixed pools, 64-byte payload, max 7 refs, priority 0 reserved). Consult before generating code.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details what rules are included (directories, invariants) and implies read-only behavior, but does not mention auth, rate limits, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first lists specifics, second gives usage context. No wasted words, front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description fully covers what the tool does and when to use it for a simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema coverage 100%. The description adds meaning by explaining the content and purpose of the tool beyond an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the rules all AK contributions must follow, listing specific off-limits directories and kernel invariants. It distinguishes itself from sibling tools like get_ak_api and get_ak_guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Consult before generating code' implies when to use, but there is no explicit when-not-to-use or mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step-by-step recipe (with skeleton code, Makefile.mk steps, and wiring) for a common AK task. Topics: agent-workflow, create-driver, create-screen, create-task, debug-uart-shell, isr-bridge, kernel-task-log, start-project, tune-pools, use-timer.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Which recipe to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention idempotency, side effects, authentication needs, rate limits, or response format (e.g., whether it returns plain text or JSON). The description only states what the tool contains, not its behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines the tool content, second lists available topics. Every sentence is necessary and no words are wasted. It is front-loaded with the core definition, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple guide-retrieval tool with one parameter and no output schema, the description is mostly complete. It explains what the tool provides and enumerates available topics. It lacks detail about the output format (structure of the returned guide), but this is a minor gap given the tool's straightforward purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the single 'topic' parameter has an enum with descriptions. The description adds value by listing the topic values in prose, reinforcing the enum. However, it does not add substantial meaning beyond what the schema already provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides step-by-step recipes with skeleton code, Makefile.mk steps, and wiring for common AK tasks. It lists 10 specific topics, making the purpose and scope unambiguous. This effectively distinguishes it from sibling tools like search_ak_docs or get_ak_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a step-by-step guide is needed, but it does not explicitly state when to use this tool over alternatives like search_ak_docs or get_ak_api. No exclusions or prerequisites are mentioned; usage context is only implied by the topic list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AK kernel API symbols, optionally filtered by module (task, message, timer, fsm, tsm, ak, port), each with a one-line summary.
| Name | Required | Description | Default |
|---|---|---|---|
| module | No | Restrict to one kernel module. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses output (one-line summary) but omits details on side effects, permissions, or pagination. Adequate for a listing tool but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded action and essential details; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 fully covers purpose and output shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. Description adds value by explaining the filter purpose and listing valid modules, exceeding the schema's enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List AK kernel API symbols' with optional filtering by module and a one-line summary, distinguishing it from sibling tools like get_ak_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly when to use (list API symbols) and mentions filtering, but lacks explicit guidance on when not to use or direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across AK concepts, guides, guardrails, and API entries. Returns ranked results with resource URIs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 8). | |
| query | Yes | Keywords, e.g. 'post message to task' or 'one-shot timer'. | |
| section | No | Restrict results to one section. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it returns ranked results with URIs, which implies read-only behavior, but does not disclose any potential side effects, authentication needs, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the core function: 'Full-text search across...' followed by result type. Each sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 elaborate on result structure or pagination, but it does mention 'ranked results with resource URIs.' For a search tool, it provides a basic understanding of what to expect, though it's somewhat sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds an example keyword but does not significantly enhance understanding beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search across AK concepts, guides, guardrails, and API entries, and returns ranked results. This distinguishes it from sibling tools like 'get_ak_api' which retrieve specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what it does but does not explicitly state when to use it over siblings or provide usage context. The sibling names imply it's for discovery, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Begin a new firmware project from the AK base kit. Resolves the LATEST ak-base-kit-stm32l151 release (or a given tag) and returns the exact commands to download, extract, and lay out the project, plus the steps to customize it. Call this when an engineer wants to start/create/bootstrap a new AK-based project.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Specific release tag, e.g. 'v1.3'. Omit to use the latest release. | |
| project_name | No | Folder name for the new project (default 'my-ak-app'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral context: it resolves the latest or given release, returns commands and customization steps, and does not directly modify the environment, which is informative for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler, front-loading the core action and result, followed by clear usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description adequately explains the return value (commands and steps) and the tool's role in project bootstrapping, making it complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with clear descriptions for both parameters. The description adds some context about 'latest release' resolution but does not significantly enhance the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Begin', 'start/create/bootstrap' and clearly identifies the resource as a new AK-based firmware project, distinguishing it from sibling tools like search_ak_docs or list_ak_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool ('when an engineer wants to start/create/bootstrap a new AK-based project'), but does not mention when not to use it or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyze_ak_logdecode_ak_lcdget_ak_guide1 field changedInput schema / properties / topic / enumPrevious value: -[
- "create-driver",
- "create-screen",
- "create-task",
- "isr-bridge",
- "tune-pools",
- "use-timer"
-]New value: +[
+ "agent-workflow",
+ "create-driver",
+ "create-screen",
+ "create-task",
+ "debug-uart-shell",
+ "isr-bridge",
+ "kernel-task-log",
+ "start-project",
+ "tune-pools",
+ "use-timer"
+]start_ak_projectv0.1.0get_ak_apiget_ak_guardrailsget_ak_guidelist_ak_apisearch_ak_docsEach tool has a clearly distinct purpose: search, API details, API listing, guide, guardrails, project start, log analysis, LCD decode. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern with underscores, using the 'ak' prefix (search_ak_docs, get_ak_api, etc.), making them predictable and easy to understand.
Eight tools is well-scoped for an embedded firmware development assistant. It covers documentation, API reference, guides, project initialization, and debugging without being overwhelming or too sparse.
The tool set covers key developer workflows: searching docs, retrieving API signatures, getting guides and rules, starting projects, and analyzing logs and LCD output. Minor gaps like a build tool or flash utility are likely out of scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Run, build, and validate firmware on virtual hardware from your AI agent. Hardware knowledge corpus.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/the-ak-foundation/mcp-docs-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
