plane-local-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Each tool targets a distinct resource or action, but the pair retrieve_issue and get_issue_by_identifier both retrieve a single issue, differing only by lookup key. This minor overlap is clarified by descriptions, so most tools are unambiguous.
Naming Consistency4/5
Names follow a verb_noun pattern with snake_case throughout, but verbs are inconsistent (list, get, retrieve, update, add, remove). This is readable but not as uniform as using the same verb for the same operation.
Tool Count5/5
With 14 tools, the server covers issues, cycles, states, labels, modules, and projects without feeling bloated. This is well-scoped for a project management integration.
Completeness3/5
The surface has strong read and update coverage for issues and cycles, but notably lacks a create_issue tool or any deletion capability. Agents cannot create new issues, so the lifecycle is incomplete.
Average 3.3/5 across 14 of 14 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'list', implying a read operation, but does not specify whether it returns active/completed cycles, sorting, pagination, or any permissions required. The output schema is present but the description adds no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the verb. However, it is under-specified to the point of being minimally informative, so it does not fully earn its place as a helpful specification beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and one parameter, so complexity is low. But the description lacks any contextual details about cycle scope, behavior, or relationship to other tools. Given the sibling set includes many list tools, more context is needed to disambiguate usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only says 'de um projeto' which maps to project_id, but gives no detail on how to obtain the ID or any constraints. This adds minimal value beyond the parameter name 'Project Id' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lista cycles de um projeto' (List cycles of a project), clearly identifying the action (listing) and resource (cycles) with a project scope. This distinguishes it from sibling tools like list_issues or list_states, though it lacks explicit mention of any filtering or scope nuances that would make it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or when another tool would be more appropriate, leaving the agent without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does not mention pagination behavior (per_page, max_pages), default expansions, or any limitations such as maximum page count. The API endpoint reference is minimal and does not add 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose, and has no wasted words. It is appropriately concise, though it could benefit from additional structure to convey usage nuances.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters including pagination controls, but the description does not explain these or any usage context. It also does not mention that output is paginated or how the endpoint works. Given no annotations and a minimal schema, this is inadequate for a list operation with multiple configuration options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of any of the four parameters (expand, per_page, max_pages, project_id). With schema description coverage at 0%, the description fails to compensate, leaving parameter meanings entirely to the schema field titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists issues of a project, with a clear verb ('Lista') and resource ('issues'). It distinguishes from siblings like retrieve_issue (singular) and list_issue_children (child issues), but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_issue_children or retrieve_issue. The description only states what it does, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention potential side effects, authentication requirements, or return format. For a list operation, this lack of transparency leaves important behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it efficient and front-loaded. However, its extreme brevity is a trade-off that omits valuable context, so it is not a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks important context such as the required project_id parameter and clarification of what 'estados' includes. While an output schema exists (so return values are covered), the usage context remains incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the project_id parameter or its purpose. The schema only provides a title 'Project Id', which is insufficient. With low coverage, the description was expected to compensate but failed to add any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista estados (colunas) de um projeto' clearly uses a specific verb ('Lista' = lists) and identifies the resource ('estados' / columns of a project). It distinguishes from sibling list tools (list_labels, list_cycles, etc.) by specifying this unique resource type, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states what the tool does, leaving the agent to infer usage context without any exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not specify whether 'children' means direct children only, whether it includes grandchildren, how errors are handled, or whether any side effects occur. The description simply restates the tool's purpose without adding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core operation and includes a concrete identifier example. There is no filler or redundant information, achieving maximum conciseness while remaining clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description is too sparse. It does not clarify what 'children' means (e.g., sub-issues, linked issues), explain the expand parameter, or provide any usage context. Given the lack of annotations, this minimal description is inadequate for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters with zero description coverage. The description mentions 'identificador' which maps to parent_identifier, but gives no information about the 'expand' parameter or its default value. This leaves half the parameter space unexplained, making the description insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista filhos') and the target resource ('issue/épico') by identifier, with an example ('CKTPC-838'). It distinguishes itself from sibling tools like list_issues and retrieve_issue by focusing on children, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like list_issues or retrieve_issue. It only describes the function without mentioning exclusions, prerequisites, or specific scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states that the tool removes an issue from a cycle, implying a mutation, but it does not explain side effects, reversibility, required permissions, or what happens if the cycle or issue is not found. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the action and followed by a specific parameter instruction. It is economical with no wasted words. However, it is so brief that it skips important details, though that is more a completeness issue than a conciseness one. It earns a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, lack of annotations, and three parameters, the description is insufficient. It does not explain the interaction between the required 'identifier' and the optional cycle_id/cycle_name, nor does it describe the expected output or error behavior. The presence of an output schema does not compensate for missing behavioral and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain that cycle_id and cycle_name are alternative identifiers for the cycle, which adds some meaning beyond the schema. However, it completely omits the required 'identifier' parameter, leaving its role unclear. The description provides only partial compensation for the parameter coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action with a specific verb ('remove') and resource ('issue from cycle'). It distinguishes itself from sibling tools like add_issue_to_cycle by naming the inverse operation. The instruction to provide either cycle_id or cycle_name adds useful scoping, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a parameter-level instruction ('Informe cycle_id ou cycle_name') but provides no guidance on when to choose this tool over alternatives. It does not mention exclusions, prerequisites, or typical use cases. The omission of the required 'identifier' parameter in the instruction also muddies usage, making the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool retrieves a project, which is a high-level behavior, but it does not disclose what happens if the UUID is not found, any authentication requirements, or whether the operation is read-only. The output schema exists, but the description itself adds minimal transparency beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. It contains no redundant words or fluff, making it optimally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no nested objects) and the presence of an output schema, the description is minimally adequate but lacks contextual depth. It does not mention how this tool relates to sibling project/issue retrieval tools, when it should be preferred, or any edge cases. The description is too sparse to fully guide an agent in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, listing only 'project_id' as a string. The description compensates by indicating that the parameter is a UUID, which adds meaningful semantic context. However, it does not provide additional detail such as format validation or examples, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: 'Recupera um projeto pelo UUID' (Retrieves a project by UUID), naming a specific verb and resource. It is easy to understand what the tool does, but it does not explicitly differentiate itself from sibling tools like list_projects or retrieve_issue, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives such as list_projects or get_issue_by_identifier, nor does it mention any prerequisites or exclusions. This leaves the agent without clear decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action of listing projects and does not specify read-only nature, return format, pagination, or any other behavioral traits, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and has an output schema, which reduces the need for detailed return documentation. However, given the presence of sibling tools and the lack of usage context, the description is only minimally complete and could benefit from mentioning its scope and relation to retrieve_project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter explanation is needed. The baseline for 0-parameter tools is 4, as the description does not need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists projects from the configured workspace, using a specific verb and resource. It distinguishes itself from siblings by focusing on 'projetos' (projects), though it does not explicitly contrast with retrieve_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 retrieve_project or list_issues. No context about prerequisites, use cases, or differentiation from siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral specifics. It only states the action, omitting whether it is read-only (though implied), any authorization requirements, or output characteristics. For a list tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, no redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the core is covered. However, the description lacks any context on required input or edge cases, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description adds no meaning to project_id beyond the schema's type and title. The single parameter is self-explanatory, but the description should still note its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista labels de um projeto' clearly states the tool lists labels for a project, using a specific verb and resource. It distinguishes from sibling tools like list_states and list_issues, which operate on different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description simply states the function without any context on use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention whether the operation is read-only, any permissions required, or pagination/limits, leaving the agent to infer these details from the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the essential purpose, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description covers the core function adequately. However, the lack of behavioral transparency and usage guidelines leaves gaps; the output schema helps complete the picture but does not substitute for these missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter project_id is implicitly described by 'de um projeto,' which clarifies it identifies the project whose modules are listed. However, with 0% schema description coverage, the description provides minimal additional detail about the parameter's format, constraints, or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista modules de um projeto' clearly states the action (lists) and resource (modules of a project). It distinguishes itself from sibling tools that list other entities like issues, states, labels, and cycles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to list modules for a given project, but it does not explicitly state when to prefer this over other list_* tools or mention any exclusions. Usage is inferred from the core purpose rather than explicitly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that it retrieves an issue, but does not mention read-only status, required permissions, return format, or side effects. This is insufficient given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose and includes an example. Every word is useful, and it is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the output schema covering return values, the description omits crucial information about the expand parameter and does not explicitly differentiate usage from the sibling retrieve_issue tool. Given the schema has no descriptions for parameters, the description should have explained them, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies the identifier parameter (human identifier) through the example. The expand parameter is completely unexplained. The description provides minimal compensation for the lack of schema descriptions, falling short of adequately explaining both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an issue by its human identifier, distinguished from alternative retrieval methods by using the term 'identificador humano' and providing a concrete example (CKTPC-838). This clearly differentiates it from sibling tool retrieve_issue, which likely uses an internal identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (when you have a human-readable identifier) without explicitly mentioning alternatives or exclusions. It implies usage over other retrieval tools but does not explicitly state 'when not to use' or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'retrieves,' implying a read operation, but does not mention error conditions, authorization requirements, or any side effects. It adds minimal context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a clear purpose and an output schema available. The description adequately conveys the retrieval by UUID, though it lacks explicit differentiation from get_issue_by_identifier which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description clarifies that project_id and issue_id are UUIDs, adding semantic meaning beyond the raw parameter names. It maps the description directly to both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving an issue by project UUID and issue UUID. The verb 'recupera' (retrieve) and resource 'issue' are specific, and the UUID qualification distinguishes it from sibling tools like get_issue_by_identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_issue_by_identifier. It does not state that this should be used when UUIDs are available or exclude other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the add action and parameter guidance, but does not disclose side effects, idempotency, permissions, or behavior when inputs are invalid. This is comparable to the mid-tier example where mutation tools need more behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Portuguese with an inline example. It is front-loaded, wastes no words, and every part adds useful information about purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers the main purpose and cycle identification, and an output schema exists so return values need not be detailed. However, it omits guidance about the required 'identifier' parameter and any behavioral nuances, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for cycle_id and cycle_name (either/or relationship, example format), but does not explain the required 'identifier' parameter. Thus it provides partial compensation for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Adiciona uma issue a um cycle' (Adds an issue to a cycle). It uses a specific verb and identifies both resources (issue and cycle), distinguishing it from sibling tools like remove_issue_from_cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: to add an issue to a cycle, and specifically instructs to provide cycle_id or cycle_name with an example format. It doesn't explicitly mention alternatives or exclusions, but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states what data is returned and adds a valuable nuance with 'edition assumida' (assumed edition), indicating the data's inferred nature. The verb 'Retorna' implies a read-only operation, setting correct expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the tool's purpose and key return fields without any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and an output schema exists, so the description adequately covers purpose and behavior. It's a simple retrieval tool, and the description is sufficient for an agent to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers them (100% coverage). The baseline for 0-param tools is 4, and the description doesn't need to add parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retorna') and clearly identifies the resource ('configuração do Plane conectado') with specific fields (base_url, workspace, edition assumida). It distinguishes itself from sibling tools that focus on issues, cycles, projects, or modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it's for retrieving instance-level configuration, which makes it obvious when to use it over siblings. However, it doesn't explicitly name alternatives or when-not-to-use scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden and discloses meaningful traits: plain-text description is converted to HTML, description_html takes precedence, and state_id/state_name moves the issue's status. It does not cover permissions, partial-update semantics, or what happens when both state parameters are provided, but the disclosed behavior is substantial for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by tightly scoped bullet points that each add parameter value. Every sentence earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter optional-heavy update tool with an output schema, the description is largely complete: it names all editable dimensions and key parameter interactions. It would be slightly more complete with explicit 'only provided fields are changed' or error-case guidance, but the output schema and clear parameter bullets keep this at a strong level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining almost every parameter: name as the issue title, description vs description_html with precedence, state_id/state_name with a pointer to list_states, priority allowed values, and the identifier example. Only minor ambiguity remains around the 'título' to 'name' mapping, but the intent is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Edita' plus the resource 'issue' and enumerates the editable fields (título, descrição, prioridade, status). It gives a concrete identifier example (CKTPC-844), making the tool's purpose unambiguous and distinguishing it from sibling list/get/cycle tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use the tool (to edit issue title, description, priority, or status) and provides an explicit reference to list_states for discovering valid state IDs/names. It does not explicitly exclude alternatives like add_issue_to_cycle, but the scope is clear enough for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![plane-local-mcp MCP server](https://glama.ai/mcp/servers/JonatanCosta/plane-local-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JonatanCosta/plane-local-mcp)

Score Badge

Copy to your README.md:

[![plane-local-mcp MCP server](https://glama.ai/mcp/servers/JonatanCosta/plane-local-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JonatanCosta/plane-local-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JonatanCosta/plane-local-mcp'

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