The mcp-boards-nk server enables full management of Mattermost Boards (Focalboard) via natural language through Claude or other MCP-compatible clients.
List Teams (list_teams): Retrieve all Mattermost teams/workspaces.
List Boards (list_boards): List all boards within a specific team.
Get Board Details (get_board): Fetch detailed board information, including properties, columns, and option values.
List Cards (list_cards): Retrieve cards/tasks from a board, with optional filtering and pagination.
Get Card Details (get_card): Fetch full details of a specific card.
Create Card (create_card): Create a new card with a title, content/description, and custom properties.
Update Card (update_card): Modify an existing card's title, content, or properties.
Delete Card (delete_card): Remove a card from a board.
Add Comment (add_comment): Post a comment on a specific card.
List Views (list_views): View all available board views (kanban, table, gallery, etc.).
List Board Members (list_board_members): See all members associated with a board.
Provides tools for managing Mattermost Boards (Focalboard), including listing teams, boards, cards, views, and members, as well as creating, updating, and deleting cards.
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., "@mcp-boards-nk list all boards in the design team"
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.
MCP server for Mattermost Boards (Focalboard) — lets Claude and other MCP-compatible clients list teams, boards, and cards, create and update tasks, add comments, and more — all via natural language.
The first MCP server with full support for Mattermost Boards (Focalboard).
Tool | Description |
| List all Mattermost teams |
| List boards in a team |
| Get board details including properties and columns |
| List cards/tasks in a board. Optional filter: |
| Get full card details |
| Create a new card with title, properties and content |
| Update title, properties or content of an existing card |
| Delete a card from a board |
| Add a comment to a card |
| List views of a board (kanban, table, gallery…) |
| List members of a board |
Related MCP server: Another Planka MCP
Self-hosted Mattermost instance with the Boards (Focalboard) plugin enabled
A Mattermost Personal Access Token
Run the interactive setup wizard — it configures Claude Desktop or Claude Code automatically:
npx --prefer-online --package=mcp-boards-nk mcp-boards-nk-setup
The wizard will ask you:
Which client to install to (Claude Desktop / Claude Code global or project)
Your Mattermost URL
Your personal access token
You can install to multiple clients in a single run.
npx --prefer-online --package=mcp-boards-nk mcp-boards-nk-setup --uninstallSelect which clients to remove the MCP from and the wizard handles the rest.
Variable | Required | Description |
| ✅ | Base URL of your Mattermost instance (no trailing slash) |
| ✅ | Personal access token of the Mattermost user |
Go to Profile → Security → Personal Access Tokens → Edit
Click Create Token, give it a name, copy the value
If the option doesn't appear, ask your Mattermost admin to enable it: System Console → User Management → Users → Manage Roles → Allow this account to generate personal access tokens
When creating or updating cards, pass properties as a JSON object using the IDs defined in the board.
Use get_board to see all available property IDs and their option values.
Example:
{
"prop_estado": "opt_pendiente"
}MIT
Agrega un comentario a una card
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | ID del board | |
| card_id | Yes | ID de la card | |
| content | Yes | Texto del comentario |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral transparency. It only says 'adds a comment', but does not disclose any behavioral traits such as required permissions, side effects, or whether the operation is idempotent. For a mutating tool, this is a significant gap.
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 sentence that conveys the core action efficiently. It is appropriately sized, though the use of Spanish might slightly hinder universal understanding.
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 absence of an output schema and annotations, the description is too minimal. It does not explain what the tool returns or any constraints on the parameters (e.g., limits on content length). For a simple tool this might be borderline, but it lacks completeness expected by an AI 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?
All three parameters are described in the input schema with brief descriptions (ID del board, ID de la card, Texto del comentario). The description adds no additional meaning beyond what the schema provides. With 100% schema coverage, baseline is 3, and no extra value is added.
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 'Agrega un comentario a una card' clearly states the action (adds) and the resource (comment to a card), making the purpose understandable. It distinguishes this tool from sibling tools like create_card or delete_card, which have different purposes. However, the description is in Spanish while the tool name is in English, which might slightly reduce clarity for some agents.
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?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without any context on prerequisites, when not to use it, or comparison to similar tools. This leaves the agent with insufficient information for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crea una nueva card/tarea en un board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | ID del board | |
| title | Yes | Título de la card | |
| properties | No | Propiedades como objeto JSON, ej: {"prop_estado": "opt_pendiente"} | |
| content | No | Contenido/descripción de la card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure, but it only says 'creates a new card'. No mention of permissions, side effects, success response, or error conditions. For a mutation tool, this is insufficient.
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, concise sentence that gets straight to the point. No unnecessary words or repetition. It is front-loaded and easy 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?
Given the tool's simplicity and full parameter documentation in the schema, the description is adequate but lacks any additional context about behavior, return values, or integration with sibling tools. It meets minimal requirements.
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%, with each parameter explained. The description adds no extra meaning beyond the schema; it merely restates the overall purpose. 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 the verb 'creates' and the resource 'card/tarea' in a 'board', using specific Spanish terms. It distinguishes from sibling tools like delete_card, get_card, update_card, etc., which handle other operations on cards.
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 provides no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions for use or avoidance. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Elimina una card de un board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | ID del board al que pertenece la card | |
| card_id | Yes | ID de la card a eliminar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only states 'deletes' without mentioning that the action is irreversible, lacks confirmation prompts, or requires specific permissions. This is a significant gap for 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise, though it could be slightly more informative without harming brevity.
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 delete tool with full schema coverage, the description is nearly complete. However, missing behavioral context (permanence, side effects) and lack of usage guidance make it only averagely 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 description coverage is 100%, so the schema already explains both parameters. The description adds no additional meaning beyond what is in the schema, earning a baseline score of 3.
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 verb 'elimina' (deletes) and the resource 'card de un board', making the purpose obvious. However, it does not differentiate from sibling tools beyond the name, but the action is distinct enough.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, error conditions, or best practices, leaving the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene detalles de un board incluyendo sus propiedades/columnas
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | ID del board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that the tool is read-only or disclose any side effects. The behavioral transparency is adequate but not enhanced beyond stating what it retrieves.
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 sentence, concise, and front-loaded with the key action and resource. Every word is relevant.
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 simplicity (one parameter, no output schema), the description is mostly complete. It could mention the return format or typical use cases, but it covers the essential information for a simple get operation.
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 a single parameter (board_id) that has a description. The description adds that it includes properties/columns, but this is more about the tool's output than the parameter itself. No additional 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 clearly states the verb 'obtiene' (gets) and the resource 'board' with details including properties/columns. It distinguishes itself from siblings like list_boards (listing boards) and get_card (getting a card).
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 the tool is for retrieving board details, but it does not specify when to use it versus alternatives like list_boards. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene el detalle completo de una card
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | ID de la card |
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 retrieves complete detail, indicating a read operation, but does not disclose behavior like authorization needs, rate limits, or side effects. It is adequate but lacks depth.
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 that efficiently states the purpose. It is concise and free of redundant information, though it could be slightly more structured (e.g., including an explicit statement of the result).
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 simplicity (one parameter, no output schema), the description is minimally complete. It does not explain what 'complete detail' includes or provide any return value information, which would be helpful given the lack 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?
Schema coverage is 100% since the only parameter 'card_id' is described. The description adds no additional meaning beyond what the schema provides, 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 retrieves the complete details of a card. It uses a verb ('obtiene') and a specific resource ('card'), distinguishing it from sibling tools like 'list_cards' which likely returns multiple cards or summaries.
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 alternatives such as 'list_cards' or 'update_card'. The description implies it is for fetching full card details, but does not specify when not to use it or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los miembros de un board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | ID del board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The minimal description only states 'lists members' but does not mention read-only nature, authorization needs, error handling, or return behavior. This leaves significant uncertainty for a tool with no annotation support.
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 short sentence that conveys the essential function without extraneous words. It is front-loaded and efficient, though it could be slightly expanded for clarity.
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 simple tool (1 parameter, no output schema), the description is too sparse. It does not mention the return format (e.g., list of member IDs or names) or any side effects. More context would help an agent understand what the tool returns or any limitations.
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 covers 100% of the parameter documentation, so the description does not need to add extra meaning. Baseline score of 3 is appropriate as the description adds no additional value 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 clearly states the action (list) and the resource (members of a board). It is specific and distinguishes from siblings like list_teams or list_views by naming the entity 'board members'. However, it does not explicitly differentiate from similar listing tools.
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 provides no guidance on when to use this tool versus alternatives like list_boards or list_cards. It lacks context on prerequisites, conditions, 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.
Lista los boards de un team
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ID del team |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the basic action without mentioning authentication, side effects, pagination, or ordering, which are critical for a read operation.
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 concise sentence, front-loaded with the key action. It is efficient but could be slightly expanded without losing brevity.
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 parameter and no output schema, the description is adequate but lacks information about return format or board structure. It is minimally complete but leaves gaps.
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%, so the schema already documents the parameter. The description adds no additional meaning beyond what the schema provides, earning baseline score.
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 verb 'Lista' and resource 'boards', with scope 'de un team', distinguishing it from siblings like list_cards or list_teams.
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 vs alternatives, though sibling tools provide implicit differentiation. The description lacks any 'when-not' or alternate recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las cards/tareas de un board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | ID del board | |
| page | No | Página (default 0) | |
| per_page | No | Cards por página (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description is minimal; does not disclose pagination behavior, error handling, or any side effects. With no annotations, fails to provide necessary behavioral context.
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, no fluff. Efficiently states purpose without unnecessary 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?
Lacks details on return structure, pagination defaults, and behavior for invalid board_ids. Incomplete for a list operation with multiple parameters.
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 3 applies. Description adds no extra meaning beyond the schema's parameter 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?
Description clearly states 'Lists the cards/tasks of a board' with a specific verb (list) and resource (cards/tasks of a board). Distinguishes from siblings like get_card (single card) and list_boards.
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 guidance on when to use this tool vs alternatives like get_card or filtering options. Lacks explicit context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista todos los teams/workspaces de Mattermost Boards
| Name | Required | Description | Default |
|---|---|---|---|
| _dummy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as return format, permissions, rate limits, or side effects. The tool likely performs a read operation, but this is not stated.
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, concise sentence that is front-loaded with the verb. However, it could include additional necessary details without losing conciseness.
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?
Despite the tool's simplicity, the description lacks completeness. It does not specify the return value format or any edge cases, and there is no output schema to compensate.
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 has 0% description coverage, and the `_dummy` parameter is not explained in the description. The description adds no meaning beyond what the schema provides.
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 action (list) and the resource (teams/workspaces of Mattermost Boards). It differentiates from sibling tools like list_boards and list_cards by focusing on teams.
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 guidance is provided on when to use this tool versus alternatives, such as list_boards or list_cards. There is no mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las vistas de un board (tablero, tabla, galería, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | ID del board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose behavioral traits such as permissions, pagination, or the exact structure of returned data. Only the basic purpose is stated.
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, but could include more information without becoming verbose. It is adequately concise but under-informative.
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 list tool with one parameter and no output schema, the description is minimally complete, but lacks details on what the returned views contain (e.g., names, types).
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% for the single parameter board_id; the description does not add additional meaning beyond what the schema already provides.
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 lists views of a board, with examples of view types (tablero, tabla, galería), and distinguishes from sibling tools which deal with cards, boards, members, etc.
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 guidance on when to use this tool versus alternatives like get_board which might also return views. No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Actualiza el título, propiedades o contenido de una card existente
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | ID de la card a actualizar | |
| title | No | Nuevo título | |
| properties | No | Propiedades a actualizar como objeto JSON, ej: {"prop_estado": "opt_completado"} | |
| content | No | Nuevo contenido/descripción |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Sin anotaciones, la descripción debe revelar comportamientos clave. Solo indica que se actualizan campos, pero no menciona si las propiedades se fusionan o reemplazan, requisitos de permisos, errores si la card no existe, ni efectos secundarios.
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?
Es una sola oración sin palabras redundantes, pero sacrifica información importante. Una descripción más útil podría incluir detalles sobre el comportamiento sin ser excesivamente larga.
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?
Para una herramienta de mutación sin esquema de salida ni anotaciones, la descripción es insuficiente. No explica el valor de retorno, condiciones de error ni cómo manejar propiedades complejas. Se requiere más contexto para un uso seguro.
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?
La cobertura del esquema es del 100%, por lo que la línea base es 3. La descripción no añade significado adicional más allá de los nombres de los parámetros; simplemente enumera los campos que se pueden actualizar.
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?
El verbo 'actualiza' y el recurso 'card existente' son claros. Especifica qué se puede modificar (título, propiedades, contenido), distinguiendo de herramientas hermanas como create_card o delete_card. Sin embargo, no menciona explícitamente que solo afecta a la card indicada por card_id.
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 proporciona orientación explícita sobre cuándo usar esta herramienta frente a alternativas. El contexto de herramientas hermanas (create_card, delete_card) sugiere que es para modificar, pero no hay 'cuándo no usarla' ni exclusiones.
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.2add_commentcreate_carddelete_cardget_boardget_cardlist_board_memberslist_boardslist_cardslist_teamslist_viewsupdate_cardEach tool clearly targets a distinct resource: cards, boards, members, teams, views, comments. No overlapping responsibilities, making it easy for an agent to select the right tool.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_card, list_boards). The verb is always imperative, and nouns are singular/plural appropriately, providing a predictable interface.
With 11 tools, the server is well-scoped for a board management system. Each tool covers a necessary operation without unnecessary duplication, striking a good balance between simplicity and functionality.
The server covers major CRUD operations for cards and provides board, member, view, team, and comment access. Minor gaps like board deletion or card reordering are missing, but the core workflows are fully supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for generating rough-draft project plans from natural-language prompts.
GibsonAI MCP server: manage your databases with natural language
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Collaborative whiteboard MCP server — create objects, connectors, C4 diagrams, and manage boards
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nikodev-documentacion/mcp-boards-nk'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
