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., "@Task Board MCP Server What is left to do?"
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.
A task-board MCP server that exercises all three server primitives — tools, resources, and prompts — plus a host that drives it with a cheap model, and a protocol-level test suite.
Part of ai_engineering.
THEORY.md covers the concepts: what MCP actually standardises and what it does
not, why the tool/resource/prompt split is about who decides rather than what
the data is, the stdio rule that breaks more servers than anything else, why
tool errors must not be thrown, annotations as host hints, and how to test a
server so its failures are visible.
npm install
npm run seed # writes a 5-task starting board
npm test # 27 protocol-level assertions, no API key neededFor the LLM host, copy .env.example to .env and add an OpenAI key:
npm run client -- "What is left to do?"
npm run client -- "Check whether anything about CI is tracked, and mark it done."Defaults to gpt-4o-mini. Tool calling does not need a frontier model — set
MODEL in .env to change it.
Related MCP server: Cerase Tasks MCP
File | Role |
| The MCP server — 3 tools, 2 resources, 2 prompts, over stdio |
| Board logic, pure and testable, knows nothing about MCP |
| A minimal host: MCP client + model + tool loop |
| Protocol test — spawns the real server over the real transport |
| Writes a starting board |
The split is about who decides, not what the data is:
Primitive | Decided by | Here |
Resources | the application |
|
Tools | the model |
|
Prompts | the user |
|
client.js shows the distinction concretely: it reads task://board itself
before the model runs, and lets the model choose when to call search_tasks.
Nothing stops you exposing the board as a tool — but then the model decides
what context to load, which is the thing resources exist to avoid.
The official interactive client. Nothing to install:
npm run inspectThat runs npx @modelcontextprotocol/inspector node server.js, which opens a
browser UI with a pre-filled session token. In it you can:
Tools → list, inspect schemas and annotations, call with arbitrary args
Resources → browse task://board, and see the template expand to real
ids. Type task://item/ and autocompletion offers ids from the live board.
Prompts → render standup with a focus argument and read the message
it produces
Errors / notifications panes → everything the server writes to stderr
The Inspector also has a CLI mode, which is what to reach for in a script:
npx @modelcontextprotocol/inspector --cli node server.js --method tools/list
npx @modelcontextprotocol/inspector --cli node server.js \
--method tools/call --tool-name search_tasks --tool-arg query=docsnpm test — for knowingThe Inspector shows you one call at a time and depends on you noticing. The test suite asserts 27 properties in about a second, with no API key and no model:
DISCOVERY every tool, resource, template and prompt is registered
SCHEMAS + ANNOTATIONS read-only, destructive, idempotent flags are correct
HAPPY PATH a write shows up in the resource
STRUCTURED OUTPUT structuredContent validates against outputSchema
THE EMPTY CASE a search with no results explains itself
ERROR HANDLING bad input returns isError rather than throwing
DISCOVERABILITY template completion and prompt arguments workIt spawns server.js as a subprocess over stdio using the SDK's own Client,
so it exercises the same transport and schemas the Inspector and Claude Code do.
It stashes any real data/tasks.json first and restores it after.
Why assert annotations. A tool marked readOnlyHint when it writes will
skip the confirmation prompt a host would otherwise show. Nothing errors. The
only place that mistake is visible is a test that reads the flag back.
claude mcp add task-board -- node /absolute/path/to/ModelContextProtocol/server.jsThen /mcp lists the server, its tools appear to the model, and /standup
shows up as a slash command.
On stdio, stdout is the protocol. Every byte must be a JSON-RPC message. A
single console.log in a handler corrupts the stream, and the client
disconnects with a parse error that names no line of your code. All diagnostics
go to console.error. THEORY.md §6 has the full argument.
Add a task to the board. Search first — this does not detect duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional labels | |
| title | Yes | What needs doing, as a short phrase | |
| status | No | Starting status | todo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already reveal this is a non-readonly, non-idempotent write. The description adds key context that no duplicate detection occurs, which is non-obvious and useful. It does not explain return value or permissions, but the core behavioral caveat is disclosed.
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 short sentences with a clear lead action and one essential caveat. No filler or repetition of schema details; every word adds value.
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 three-parameter creation tool with no output schema, the description covers purpose, usage, and a critical edge case. It could mention what is returned or that the task is immediately placed on the board, but the provided information is sufficient for safe invocation.
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 all parameters are already well-documented with descriptions and defaults (tags, title, status). The description adds no additional parameter semantics, so baseline 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?
States a specific action and resource: 'Add a task to the board.' This clearly distinguishes create_task from sibling search_tasks and set_status, and the dedup warning reinforces that it is a creation operation.
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 instructs the agent to search first because the tool does not detect duplicates, effectively telling when to use search_tasks before invoking create_task. This gives clear behavioral guidance for avoiding duplicate creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tasks whose title or tags contain the query. Use this before creating a task to avoid duplicates. Returns a note describing what was searched, including when nothing matched.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Substring to look for in titles and tags | |
| status | No | Restrict to one status |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals that the tool returns a note describing the search, and that it handles empty results gracefully. This adds context about the output and non-error behavior.
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: the first states the core function, the second adds a use case and return behavior. Every word is necessary.
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?
With a full schema, readOnlyHint, and an output schema, the description covers the search scope, a use case, and return behavior. It's complete for this tool's complexity.
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 fully describes both parameters with clear descriptions. The tool description adds no new parameter-level details, so baseline 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 the tool finds tasks by title or tags, with a specific verb and resource. It distinguishes itself from siblings by also mentioning its role in duplicate avoidance before creating.
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?
It explicitly advises using this tool before creating a task to avoid duplicates, which is a clear use case. It does not mention when not to use it or alternatives, but the instruction is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a task to one of: todo, doing, done.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task id, as shown on the board | |
| status | Yes | New status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that the tool is write-oriented, destructive, and idempotent. The description adds no extra behavioral context such as side effects, permissions, or error handling, but it also does not contradict the annotations. The additional value over annotations is minimal.
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, front-loaded sentence with no filler. It delivers the essential information (what the tool does and the allowed values) in the most efficient way possible.
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?
With only two parameters, full schema coverage, and clear annotations, the description is largely sufficient for a simple mutation tool. It does not clarify the return value or error behavior, but these are less critical given the tool's simplicity and the absence of an output schema.
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 schema already provides full descriptions for both parameters (id and status), and the enum values are repeated in the description. No extra nuance or format details are added beyond what the schema already states, so the baseline of 3 applies.
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 a specific verb ('Move') with a clear resource ('a task') and enumerates the exact allowed statuses, making its purpose unambiguous. It is clearly distinct from sibling tools like search_tasks and create_task.
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 tool name and description make the intended use obvious, and the sibling tool names (search_tasks, create_task) show a natural functional separation. However, it does not explicitly state when not to use it or mention alternatives, missing a 5.
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.0create_tasksearch_tasksset_statusThe three tools have clearly distinct purposes: searching, creating, and updating status. No overlap or ambiguity exists between them.
All tool names follow a consistent verb_noun pattern with lower snake_case: search_tasks, create_task, set_status. This makes the API predictable and easy to navigate.
With only three tools, the server is tightly scoped to its purpose as a minimal task board. Each tool earns its place and there is no bloat.
The core lifecycle of creating, searching, and updating task status is covered. Missing delete and full task editing are minor gaps, but the essential workflow is functional.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for generating rough-draft project plans from natural-language prompts.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Kanban board for teams and coding agents: manage tasks, subtasks, sprints and wiki pages via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexisinwork/MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
