wt-mcp

by felipemdf

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes: listing, creating, syncing, removing, and diagnosing. Minor overlap exists between create_task and create_with_preset, and between remove and add_project, but descriptions clarify the differences.
Naming Consistency3/5
Names mix styles: some are verb_noun (list_tasks, create_task), while others are bare verbs (sync, remove, status, prune) or noun-ish (workspace_path, open_workspace). This inconsistency makes it less predictable, though still readable.
Tool Count5/5
With 13 tools, the server is well-scoped for managing development tasks and projects. Each tool addresses a distinct need without being overwhelming.
Completeness4/5
The tool surface covers core lifecycle operations: create, list, resolve, add, remove, sync, status, and maintenance. Minor gaps exist (e.g., no explicit update/rename task), but the set is sufficient for the domain.
Average 3/5 across 13 of 13 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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?
Annotations are absent, so the description must fully disclose behavioral traits. It only states 'Fetch + rebase/merge', omitting critical details like the mutating nature of the operation, conflict behavior, the effect of force or dry_run, and implications for local branches. This is insufficient for a potentially 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it under-specifies a tool with 6 parameters and multiple behavioral options. It is front-loaded, but not appropriately sized for the complexity, making it closer to under-specification than conciseness.
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 an output schema exists, the description lacks details on operation scope, multi-project behavior, and interactions between parameters. It leaves the agent without enough context to correctly invoke the tool or interpret outcomes.
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 explain any parameters. The only indirect hint is that the task is the central context, but force, dry_run, project, strategy, and product_root remain undefined. The description adds no value beyond the schema's bare field names/titles.
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 fetches and rebases/merges on the registered base for each project of the task. It uses a specific verb and resource combination that distinguishes it from sibling tools like create_task, status, or prune, though it does not explicitly name an alternative.
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 sync versus alternatives. The description implies a synchronization use case but does not state when it is appropriate, when it is not, or which sibling tool to prefer in 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 disclosure burden. It reveals a default branch behavior, but does not mention side effects of adding projects, the dry_run option, or any potential destructive actions. It implies mutation (creates/adds) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It front-loads the primary action and adds a useful default rule, though it could include more structured details without sacrificing brevity.
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 complexity (7 parameters, multiple sibling tools, and an output schema), this description is notably incomplete. It doesn't explain the output, prerequisites, or how preset projects interact with existing tasks. The output schema exists, but the behavioral context is too thin for reliable agent use.
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 implicitly references 'task', 'preset', and 'branch'. It adds context for the branch default but does nothing to explain base_overrides, branch_overrides, dry_run, or product_root, leaving the agent to guess their meaning.
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 creates a task and adds preset projects, which distinguishes it from siblings like create_task and add_project. However, it doesn't elaborate on what a 'preset' is or how projects are added, so it stops short of full clarity.
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 explicit guidance is provided about when to use this tool versus create_task or add_project. The description only states what it does, leaving the agent to infer usage based on the name and context.
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 offers no details on behavior such as whether it requires a product_root, how results are ordered, or potential side effects, leaving significant gaps.
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, direct sentence with no filler, effectively communicating the core action and scope. It earns its place without unnecessary length.
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 having an output schema, the description is incomplete due to missing parameter semantics and no usage guidance. It lacks essential context for an agent to confidently invoke the tool, especially without annotations.
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 product_root parameter at all. With only one parameter, the description should compensate but fails to provide any meaning beyond 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 clearly states it lists tasks with statuses (empty/ready/broken) and includes projects and branches. This distinguishes it from sibling tools like list_projects, though the phrasing 'do estado' is slightly ambiguous.
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. The description simply states what it does without any context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral requirement: confirmation (confirm=true) or a dry run (dry_run) is needed, which alerts the agent to the destructive nature of the tool. However, with no annotations provided, it fails to mention other side effects such as whether delete_branch removes a branch, whether removal is reversible, or what happens to linked resources.
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 very concise—one sentence for purpose and one for the requirement—making it easy to scan. It is front-loaded with the core action. However, the phrasing 'Exige confirm=true (ou dry_run)' is somewhat cryptic and could be more explicit about the conditional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 6 parameters and no annotations or schema descriptions, this description is far from complete. It lacks details on key options like delete_branch and product_root, does not explain the effects of removal, and provides no information about return values despite having an output schema. The agent would be unable to use this tool safely and correctly based on the description alone.
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 input schema has 0% description coverage, so the description bears full responsibility for explaining parameters. It only hints at 'project' and 'task' through the main action, leaving confirm, dry_run, product_root, and delete_branch completely unexplained. This is a severe gap for a 6-parameter tool.
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 verb (remove) and the two target resources: a project from a task or the entire task. It is specific enough to distinguish from sibling tools like prune, though it does not precisely define the semantics of 'removing a project from a task' (e.g., unlinking vs deleting).
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 only usage guidance is the requirement to set confirm=true or dry_run, which is a safety prerequisite rather than guidance on when to choose this tool over alternatives. No exclusions or comparisons to sibling tools are provided, leaving the decision context unclear.
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 behavior. It reveals that fix=true requires confirmation, indicating a mutating action, but does not explain what 'diagnoses' does, the role of dry_run, or any side effects of fixing. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose and the key fix/confirm behavior with no unnecessary words. It is perfectly concise.
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?
With 4 parameters, no annotations, no parameter descriptions, and sibling tools that may overlap, the description is too brief to provide complete context. It doesn't cover the scope of diagnosis, the dry-run option, or when to use fix.
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 adds meaning for fix (attempts correction) and confirm (required for fix), but dry_run and product_root are left completely unexplained, leaving the agent with incomplete information for safe 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 tool diagnoses inconsistencies and can attempt to fix them with fix=true. This is a specific verb+resource, but it doesn't differentiate from sibling tools or specify the type of inconsistencies.
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 explicit guidance is provided on when to use this tool versus alternatives. The description implies it is for diagnosing inconsistencies, but there are no exclusions, prerequisites, or alternative 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?
No annotations are present, so the description must carry the full burden. It merely states the action without disclosing side effects (e.g., launching the editor), prerequisites, or behavior if the file is missing. This is minimal but not misleading.
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, focused sentence with no redundant or extraneous words. It is appropriately brief, though it could be slightly more informative without becoming verbose.
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 having an output schema, the description provides no context about required parameters, expected behavior, or how the workspace is opened. This makes the tool under-specified for reliable invocation.
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 fails to mention the 'task' or 'product_root' parameters. The agent has no explanation for what these parameters mean or how they affect the action, leaving a significant 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 action (opens) and the specific resource (.code-workspace) in a named target (Cursor/VS Code). This distinguishes it from sibling tools like list_tasks or resolve_product, which have different purposes.
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. The description only states what it does, leaving the agent to infer that it should be used when the workspace file needs to be opened in an editor.
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 side effects and behavior. It implies a read-only summarizing operation via 'resume', but does not clarify what 'resolve' means (e.g., file resolution, software initialization), whether it mutates state, or any prerequisites. This leaves significant behavioral ambiguity.
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, concise and front-loaded with the main action. It does not waste words, though the terseness contributes to ambiguity. It earns a high score for efficiency, not clarity.
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 optional parameter and an output schema, which reduces the need to document return values. However, the description lacks usage context and fails to explain the relationship to sibling tools. It covers the basic function but leaves gaps for an agent to confidently invoke it.
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 coverage is 0%, so the description must explain the parameter 'product_root'. It only hints at 'produto' (product) but does not explicitly describe the parameter, its format, or role. This does not compensate for the missing schema description.
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 uses a specific verb 'resolve' (though ambiguous) and 'resume' (summarize), indicating the tool aggregates name, projects, presets, and tasks. This distinguishes it from the sibling list/create tools, though the meaning of 'resolve' is unclear without context.
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 like list_projects or list_tasks. It only states what it does, leaving the agent to infer its use case without explicit context 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?
With no annotations, the description carries the full burden but only states that it lists projects from config.yml. It does not disclose side effects, return format, or behavior when product_root is specified. However, it does imply a read-only operation, so it is not entirely absent.
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, direct sentence that communicates the tool's core purpose without redundancy. It earns every word.
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 return values are defined. However, the optional product_root parameter is completely unexplained, and there's no mention of prerequisites like config.yml location. The description is minimally sufficient but leaves gaps in parameter context.
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 schema has one optional parameter (product_root) with 0% description coverage, and the tool description does not mention it. The agent is left without any explanation of how or when to supply product_root, making the parameter effectively undocumented.
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 verb 'Lista' (lists) and the resource 'projetos configurados no config.yml' (projects configured in config.yml), specifying both the action and data source. This distinguishes it from sibling tools like list_tasks and add_project.
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 does not mention that it is the read-only counterpart to add_project/remove, nor does it describe any preconditions such as config.yml needing to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool creates a folder, workspace, and state, and explicitly notes that git worktrees are not created. However, with no annotations, it omits important behavioral details such as permissions, side effects, reversibility, or whether dry_run is a safety mechanism.
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, front-loaded sentence that communicates the core function and a key exclusion without any filler. It is concise and efficiently structured.
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?
For a creation tool with three parameters and no annotation support, the description is too sparse. It fails to mention the dry-run option, product_root semantics, or when to choose this tool over 'create_with_preset', leaving critical context gaps.
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 zero information about the 'task', 'dry_run', or 'product_root' parameters. Since the schema has 0% description coverage, the agent is left to guess parameter meanings from names alone, which is insufficient.
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 states a specific verb ('Cria') and resource ('task'), and adds qualifiers 'vazia' (empty), 'pasta + workspace + estado', and 'sem worktrees git'. This clearly scopes the tool and differentiates it from the sibling 'create_with_preset', making its 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?
No explicit guidance is provided on when to use this tool versus alternatives like 'create_with_preset'. The 'empty' qualifier implies use for tasks without presets, but it is not clearly stated, and there are no prerequisites or exclusion criteria.
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 must disclose behavioral traits, but it only states a generic 'adds' action. It fails to mention side effects (e.g., whether this modifies the task permanently), the role of the 'dry_run' parameter, or any permission requirements. This is a significant gap for a mutation-type 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 a single, focused sentence that immediately conveys the core operation. It contains no fluff, redundant phrasing, or unnecessary details, making it efficient 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 tool's complexity (6 parameters, no annotations, no visible output schema details), the description is too sparse. It does not explain return values, side effects, or the significance of optional parameters like 'dry_run' or 'base'. An agent would lack essential context to invoke this tool correctly and safely.
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?
With 0% schema description coverage, the description must compensate for parameter explanations. It partially clarifies that 'project' is a config name, but it ignores the other five parameters (base, branch, dry_run, product_root, task) entirely, leaving them ambiguous. This is insufficient for an agent to construct valid calls.
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 ('adds') and the resource ('a project to an existing task'), with the scope of adding by config name. This distinguishes it from siblings like create_task or list_projects, as it specifically targets adding to an existing task.
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 associate a project with an existing task, but it does not provide explicit guidance on when to choose this over alternatives, nor does it mention any prerequisites or exclusions. The context of 'existing task' offers some usage signal, but lacks the detail needed for clear decision-making.
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 core action ('returns git status lines') without disclosing potential side effects, prerequisites, or operational details. This is minimal transparency for a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and concise, effectively conveying the tool's function in a compact form.
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 lack of annotations and minimal description, the tool is incomplete for an agent to understand when and how to use it. Although an output schema exists, the description does not provide sufficient operational context or edge-case behavior, making it insufficient for reliable 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?
Schema description coverage is 0%, so the description must compensate. It references 'task' implicitly via 'da task' but does not mention 'product_root' or explain its purpose. The description provides only partial semantic context for the 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 uses a specific verb ('Retorna') and resource ('git status de cada projeto da task'), clearly indicating what the tool does. It distinguishes from siblings because none of the listed sibling tools appear to provide git status functionality.
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 usage (when you want git status for projects in a task) but provides no explicit when/when-not guidance or mention of alternatives. It does not exclude any scenarios, but it also does not offer context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions a safety mechanism (confirm/dry_run) and indicates destructiveness via 'Remove'. However, it omits explicit statements about permanence, what happens without confirm (likely a no-op), and the scoping role of product_root. The confirm/dry_run disclosure is valuable but not exhaustive.
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 extremely concise, only two short sentences. It front-loads the core purpose immediately and then gives the usage requirement. There is no filler or redundant information, making it appropriately sized for a simple tool.
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?
An output schema exists, so return values are covered. The description covers the main action and the confirm/dry_run behavior, but it fails to explain 'product_root' and does not distinguish from sibling 'remove', leaving some ambiguity about its exact scope. For a destructive tool, it is mostly complete but has identifiable gaps.
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 schema has 3 parameters with no individual descriptions (0% coverage). The description adds meaning by indicating 'confirm' and 'dry_run' are toggles for executing vs previewing the operation. However, 'product_root' is not mentioned, leaving its purpose and effect unexplained, so the description does not fully compensate for the lack of schema descriptions.
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 action: "Remove pastas órfãs e worktrees git fantasma" (remove orphan folders and ghost git worktrees). This is a specific verb and resource, distinguishing it from siblings like 'remove' which likely targets tasks/projects. It is not tautological and leaves no ambiguity.
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 a usage prerequisite: "Exige confirm=true (ou dry_run)" (requires confirm=true or dry_run), which tells the caller how to invoke the tool safely. However, it does not explicitly discuss when to choose this over alternatives or provide exclusions, but the context is clear for when cleanup is needed.
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 discloses a key behavioral trait: it does not open the editor. This is important because the sibling tool likely opens the workspace. It also implies a read-only operation by returning a path. Error behavior and permissions are not mentioned, but for a simple lookup this is acceptable.
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, front-loaded with the action, and contains no filler words. Every word earns its place, making it highly concise and well-structured.
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 with an output schema, the description covers the primary purpose and the key behavioral distinction (not opening). However, the lack of parameter explanations, especially 'product_root', leaves gaps in understanding. The tool is simple enough that the description is mostly adequate, but not fully complete.
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 indirectly references 'task' but does not explain the meaning or format of 'task' or 'product_root'. The optional 'product_root' parameter is completely unexplained, leaving ambiguity for the agent.
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 it returns the .code-workspace path for a task and explicitly notes it does not open the editor, which distinguishes it from the sibling tool 'open_workspace'. The verb 'returns' is specific and the resource (path) is unambiguous.
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 implies a usage context by contrasting with opening the editor: use this when you only need the path, not when you need to open the workspace. However, it doesn't explicitly name 'open_workspace' as the alternative, but the negation 'não abre o editor' serves as a clear when-not-to-use indicator.
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:

[![wt-manager MCP server](https://glama.ai/mcp/servers/felipemdf/wt-manager/badges/card.svg)](https://glama.ai/mcp/servers/felipemdf/wt-manager)

Score Badge

Copy to your README.md:

[![wt-manager MCP server](https://glama.ai/mcp/servers/felipemdf/wt-manager/badges/score.svg)](https://glama.ai/mcp/servers/felipemdf/wt-manager)

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/felipemdf/wt-manager'

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