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., "@plane-mcp-server list all issues assigned to me"
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 Model Context Protocol (MCP) server acting as a bridge to the Plane.so API. 🚀
This server allows MCP clients (like AI assistants or other tools) to interact with Plane.so resources (initially Issues) through defined tools.
Related MCP server: Plane MCP
This section provides information for users who want to install and run the Plane.so MCP server to connect it with their MCP client (e.g., Cursor, Claude App).
The server exposes the following tools to interact with the Plane.so API. Tool names use underscores (e.g., plane_get_issue).
plane_get_issueRetrieves details of a specific issue.
Parameters:
project_id (string, required): ID of the project containing the issue.
issue_id (string, required): ID of the issue to retrieve.
Example:
{
"project_id": "your_project_id_here",
"issue_id": "your_issue_id_here"
}plane_create_issueCreates a new issue in a specified project.
Parameters:
project_id (string, required): ID of the project where the issue should be created.
name (string, required): Title of the issue.
description_html (string, optional): HTML description of the issue (Plane API often requires this format).
priority (string, optional): Priority of the issue ("urgent", "high", "medium", "low", "none").
state_id (string, optional): ID of the state for this issue.
assignees (array, optional): Array of user IDs to assign to this issue.
Example:
{
"project_id": "your_project_id_here",
"name": "New Feature Request",
"description_html": "<p>Details about the new feature.</p>",
"priority": "medium"
}plane_update_issueUpdates an existing issue in a project.
Parameters:
project_id (string, required): ID of the project containing the issue.
issue_id (string, required): ID of the issue to update.
name (string, optional): Updated title of the issue.
description_html (string, optional): Updated HTML description of the issue.
priority (string, optional): Updated priority of the issue.
state_id (string, optional): Updated state ID of the issue.
assignees (array, optional): Updated array of user IDs assigned to this issue.
Example:
{
"project_id": "your_project_id_here",
"issue_id": "your_issue_id_here",
"priority": "high",
"assignees": ["user_id_1"]
}Node.js (v20 or higher recommended)
A Plane.so account and an API Key -> Workspace Icon (top left) -> Settings -> API Tokens -> Add API Token
Plane.so Workspace slug -> https://app.plane.so/{workspace_slug}/ (Replace {workspace_slug} with your actual workspace slug)
npm installThe server will start and listen for requests on its standard input (stdin) and send responses to its standard output (stdout). You need to configure your MCP client (like Cursor, Claude App, etc.) to launch this server process when needed.
For more details on the Model Context Protocol, visit modelcontextprotocol.io.
Here are some example prompts you could give your AI assistant (once the server is configured in it):
"Get the details for issue BUG-123 in the WebApp project."
"Create a new high-priority issue in the API project titled 'Refactor authentication module' with the description 'Need to update the auth library.'"
"Update issue FEAT-45 in the Design project and assign it to user_abc."
Your assistant will use the appropriate tools (plane_get_issue, plane_create_issue, plane_update_issue) and likely ask for your confirmation before making changes.
API Key Security: Your PLANE_API_KEY stored in the .env file grants access to your Plane.so workspace. Keep this file secure and never commit it to version control.
Permissions: Ensure the API key used has the necessary permissions within Plane.so to perform the actions required by the tools (e.g., read issues, create issues, update issues).
User Approval: Most MCP clients will require your explicit approval before executing actions that modify data (like creating or updating issues), providing a safety layer.
This section is for developers who want to contribute to the project, run tests, or use the development environment.
npm run devThe project follows a domain-driven organization:
src/
├── configs/ # Environment and configuration
├── plane-client.js # API client wrapper
├── schemas/ # Zod validation schemas
│ ├── tools.schema.ts # Common tool schemas and utilities
│ ├── project.schema.ts # Project-specific schemas
│ └── issue.schema.ts # Issue-specific schemas
├── services/ # Service layer for API interactions
│ ├── project.service.ts
│ └── issue.service.ts
├── tools/ # MCP tool definitions and handlers
│ ├── index.ts # Tool registration
│ ├── project.tools.ts # Project tool definitions
│ └── issue.tools.ts # Issue tool definitions
└── types/ # TypeScript type definitionsThe project uses Zod for comprehensive validation:
Schema Definition: Domain-specific schemas are defined in src/schemas/
Schema Validation: The validateWithSchema utility ensures consistent validation
Error Handling: Custom ValidationError class for structured error reporting
Example of using validation:
// In a service method
const validData = validateWithSchema(MySchema, inputData);
// validData is now correctly typed and validatedTo add a new tool:
Define the tool interface in the appropriate domain file (e.g., src/tools/issue.tools.ts)
Add validation schemas in the domain schema file (e.g., src/schemas/issue.schema.ts)
Implement the service method in the service file (e.g., src/services/issue.service.ts)
Register the tool in src/tools/index.ts
The project includes multiple types of tests:
Run unit tests (fast, no API calls):
npm run test:unitThese tests make real API calls, so they need API credentials:
Create a .env.test file with:
API_KEY=your_plane_api_key
WORKSPACE_SLUG=your_workspace_slugRun integration tests:
npm run test:localQuick endpoint check:
npm run check:localThe pre-commit hooks only run linting and formatting, not tests. This ensures:
Faster commits
No API call requirements during development
No need for API credentials during regular development
When you want to run tests manually:
# Unit tests only
npm run test:unit
# All tests including integration (needs API credentials)
npm testCheck for linting and formatting errors using Biome:
npm run lint
npm run format:checkApply formatting and lint fixes automatically:
npm run format(Note: Formatting is also automatically applied on commit via Husky and lint-staged!)
Contributions are welcome! Please see CONTRIBUTING.md for details on how to contribute, report bugs, or suggest features.
We are committed to providing a welcoming and inclusive environment. Please review our CODE_OF_CONDUCT.md.
This project is licensed under the MIT License - see the LICENSE file for details.
Create a new issue
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The ID of the project where the issue will be created | |
| name | Yes | Name of the issue | |
| project | No | The ID of the project where the issue will be created | |
| description | No | Description of the issue | |
| description_html | No | HTML description of the issue | |
| priority | No | Priority of the issue (urgent, high, medium, low, none) | |
| state | No | ID of the state for this issue | |
| assignees | No | Array of user IDs to assign to this issue | |
| labels | No | Array of label IDs to apply to this issue | |
| parent | No | ID of the parent issue, if this is a sub-issue | |
| start_date | No | Start date in YYYY-MM-DD format | |
| target_date | No | Target completion date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It merely says 'Create a new issue' without revealing side effects, permissions needed, error handling, or what the tool returns, which 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 only 4 words, which is under-specified for a tool with 12 parameters and no output schema. It does not earn its place by adding value, and the brevity hinders 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 tool's complexity (12 parameters, no output schema, no annotations), the description is woefully incomplete. It fails to address return values, error states, or constraints, leaving critical 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?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no additional meaning or context 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 'Create a new issue' clearly states the verb and resource, and while brief, it correctly indicates the tool's primary action without confusion. It distinguishes from sibling tools like 'create-project' by specifying 'issue'.
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 'update-issue' or 'delete-issue'. There is no mention of preconditions, context, or when-not-to-use, leaving the agent with no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new project
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the project | |
| identifier | Yes | Unique identifier for the project (e.g., PROJ) | |
| description | No | Description of the project | |
| network | No | Project visibility (0 = Secret, 2 = Public) | |
| emoji | No | HTML emoji DEX code without the '&#' | |
| module_view | No | Enable/disable module view for the project | |
| cycle_view | No | Enable/disable cycle view for the project | |
| issue_views_view | No | Enable/disable issue views for the project | |
| page_view | No | Enable/disable page view for the project | |
| inbox_view | No | Enable/disable inbox view for the project | |
| archive_in | No | Months in which to auto-archive issues (0-12) | |
| close_in | No | Months in which to auto-close issues (0-12) | |
| default_assignee | No | UUID of user to auto-assign issues to | |
| project_lead | No | UUID of the project lead user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Create a new project' without describing side effects, authorization needs, idempotency, or return behavior, which 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 extremely short (4 words), which is concise but may be too minimal for a tool with 14 parameters. It states the purpose but lacks supporting detail. Score reflects adequate but not optimal 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?
Given the complexity (14 parameters, no output schema), the description is incomplete. It does not explain what creating a project entails, expected outcomes, or any constraints beyond the schema. More detail is needed.
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 the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter relationships or usage context. Therefore, a 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 'Create a new project' clearly states the action and resource. It distinguishes the tool from siblings like create-issue or delete-project, making the purpose unambiguous.
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, context, or exclusions are mentioned, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an issue
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The ID of the project | |
| issue_id | Yes | The ID of the issue to delete |
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 irreversibility, permission requirements, or side effects. It merely states the action.
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 extremely concise at three words, which is efficient for a straightforward delete action. No unnecessary information is included.
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 lack of an output schema and annotations, the description should explain the return behavior or success/failure handling. It does not, leaving the agent without important context for a destructive 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?
Both parameters (project_id and issue_id) have descriptions in the input schema, so the tool description adds no extra meaning. With 100% schema coverage, the baseline score 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 'Delete an issue' clearly specifies the action (delete) and resource (issue), distinguishing it from sibling tools like create-issue or get-issue. However, it does not mention the project context, which is required as a parameter.
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 update-issue or delete-project. The description lacks any context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a project
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ID of the project to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fails to disclose behavioral traits like irreversibility, cascading effects, or permission requirements. The bare statement 'Delete a project' is insufficient for safe invocation.
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 extremely concise at four words, which is appropriate for a simple operation. It is front-loaded and avoids unnecessary detail, though it could include a brief behavioral note without becoming verbose.
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 lack of output schema and annotations, the description is incomplete. It omits critical behavioral context for a destructive operation, such as confirmation prompts or post-deletion effects, which are essential for safe 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% and the input schema provides a description for the sole parameter. The tool description adds no additional meaning, 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 action (delete) and the resource (project), aligning with the tool name. It distinguishes from sibling tools like delete-issue by specifying 'project'. However, it adds no extra clarity beyond the name, lacking scope or context.
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 compared to alternatives such as update-project or delete-issue. There is no mention of prerequisites or situations where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an issue by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The ID of the project | |
| issue_id | Yes | The ID of the issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action, omitting details like error handling (e.g., behavior if issue not found), rate limits, or authentication needs. Minimal disclosure beyond the basic function.
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, front-loaded with the main action and resource. No fluff or redundancy; every word earns its place.
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 GET operation with no output schema, the description should at least hint at the return format or behavior on missing IDs. It currently does not, leaving agents uncertain about expected outcomes.
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% (both parameters described by name and type), and the description does not add further meaning beyond the schema. 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 action ('Get') and resource ('an issue'), and distinguishes it from sibling tools like create-issue or delete-issue by the verb and scope (by 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 guidance on when to use this tool vs alternatives, no context on prerequisites or limitations. The description simply states what it does without any usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific project
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ID of the project to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden of behavioral disclosure. It only states 'Get detailed information,' omitting any details about authentication, rate limits, or what 'detailed' encompasses. For a read operation, it is minimally transparent.
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, clear sentence with no extraneous words. It is front-loaded and efficient, earning its place.
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 get operation with one parameter and no output schema, the description is adequate but lacks context about the return format or any prerequisites. It does not fully compensate for the absence of annotations or additional behavioral notes.
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%, and the parameter 'project_id' is adequately described in the schema as 'ID of the project to retrieve.' The description adds no extra meaning beyond that, meeting the baseline for parameter semantics.
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 detailed information about a specific project, using a specific verb+resource structure. It successfully distinguishes from sibling tools like create-project, delete-project, and get-issue.
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-projects or get-issue. There are no exclusions, prerequisites, or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all issues in a project
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The ID of the project to list issues from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the burden of transparency. It only says 'list all issues' without disclosing pagination, sorting, or any behavioral constraints like read-only nature.
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, achieving high conciseness while conveying the essential purpose.
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 and no annotations, the description is too minimal. It lacks details like return format, pagination behavior, or any limitations, leaving the agent underinformed.
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% as the parameter 'project_id' is described inline. The tool description adds no additional meaning beyond the schema, so a 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 'List', the resource 'issues', and the scope 'in a project'. It is specific and distinct from sibling tools like create-issue or list-projects.
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 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.
List all projects in the workspace
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully describe behavior. It is minimal, only stating a read operation. It lacks details on pagination, ordering, or whether results are 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?
The description is extremely concise at 5 words, with no filler. Every word is informative and 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?
For a no-parameter list tool, the description is mostly complete. It specifies workspace scope, but could mention if results are limited or paginated. Still adequate for the simplicity.
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 tool has no parameters, so schema coverage is 100%. The description does not need to add parameter details, and it appropriately avoids extraneous information.
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), the resource (projects), and the scope (in the workspace). It effectively distinguishes from sibling tools like get-project (single project) and create-project.
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 like get-project. Usage is implied but not clarified with when-not or specific contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an issue
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The ID of the project | |
| issue_id | Yes | The ID of the issue to update | |
| name | No | Updated name of the issue | |
| description | No | Updated description of the issue | |
| description_html | No | Updated HTML description of the issue | |
| priority | No | Updated priority of the issue (urgent, high, medium, low, none) | |
| state | No | Updated ID of the state for this issue | |
| assignees | No | Updated array of user IDs to assign to this issue | |
| labels | No | Updated array of label IDs to apply to this issue | |
| parent | No | Updated ID of the parent issue, if this is a sub-issue | |
| start_date | No | Updated start date in YYYY-MM-DD format | |
| target_date | No | Updated target completion date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It does not mention that the tool modifies existing data, requires the issue to exist, or any side effects. This is a critical 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?
While extremely short (4 words), it is under-specified rather than concise. It lacks front-loading of key information like what fields can be updated or the effect of the operation.
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 12 parameters, no output schema, and no annotations, the description is woefully incomplete. It should explain return values, required permissions, or behavioral nuances.
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 the input schema already documents all parameters. The description adds no additional meaning, but the baseline for high coverage is 3. No enhancement is needed for parameter understanding.
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 'Update an issue' is nearly a tautology of the tool name. It distinguishes from siblings only through the verb 'update', but provides no detail on what an issue is or what updating entails.
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 create-issue or get-issue. No context on prerequisites, when not to use, or typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a project
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ID of the project to update | |
| name | No | Updated name of the project | |
| description | No | Updated description of the project | |
| network | No | Updated project visibility (0 = Secret, 2 = Public) | |
| emoji | No | Updated HTML emoji DEX code without the '&#' | |
| module_view | No | Updated module view setting | |
| cycle_view | No | Updated cycle view setting | |
| issue_views_view | No | Updated issue views setting | |
| page_view | No | Updated page view setting | |
| inbox_view | No | Updated inbox view setting | |
| archive_in | No | Updated months for auto-archiving (0-12) | |
| close_in | No | Updated months for auto-closing (0-12) | |
| default_assignee | No | Updated UUID of default assignee | |
| project_lead | No | Updated UUID of project lead |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It fails to disclose whether updates are partial or full, idempotent, or require specific permissions. The brief description does not compensate for the lack of annotation 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?
The description is extremely concise (four words), but at the cost of omitting useful detail. It is front-loaded but lacks any structural elements to aid quick comprehension. Acceptable for a simple tool but could be improved.
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 14 parameters, no output schema, and no annotations, the description does not cover key aspects like update behavior (partial vs full), response format, or error conditions. The tool definition is incomplete for effective agent 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 description coverage is 100%, with each parameter having a clear description. The tool description does not add additional parameter information, but the schema already provides sufficient semantics, justifying 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 'Update a project' clearly states the verb and resource. It distinguishes from sibling tools like 'update-issue' or 'create-project', but does not add specificity beyond the tool name itself.
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 (e.g., create-project, delete-project). Lacks prerequisites, context, or exclusions, leaving the agent uninformed about appropriate usage scenarios.
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.
v0.4.0create-issuecreate-projectdelete-issuedelete-projectget-issueget-projectlist-issueslist-projectsupdate-issueupdate-projectEach tool clearly targets either an issue or a project with distinct actions. There is no overlap or confusion between tools.
All tools follow a consistent hyphen-separated verb-noun pattern (e.g., create-issue, delete-project), making the naming predictable and easy to parse.
10 tools provide full CRUD coverage for both issues and projects. The count is balanced and appropriate for the domain.
The toolset covers all basic lifecycle operations (create, read, update, delete, list) for both issues and projects, leaving no obvious gaps for a minimal project management server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, read and create Linear issues, projects, teams and cycles.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Novalya-Labs/plane-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
