MCP DevOps Plan Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PLAN_SERVER_URL | Yes | The URL of your Plan server (e.g., https://your-plan-server.com/plan) | |
| PLAN_ACCESS_TOKEN | Yes | Your base64 encoded token for authentication with Plan | |
| PLAN_TEAMSPACE_ID | Yes | Your teamspace ID in Plan |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_available_projectsB | Get the list of projects in Plan for a given application |
| get_available_componentsC | Get the list of components for a project in Plan for a given application |
| get_sprintsB | Get the list of sprints in Plan for a given application |
| get_releasesB | Get the list of releases in Plan for a given application |
| create_or_update_sprintA | Creates a new sprint or updates an existing sprint in Plan. If sprintDbid is provided, updates the sprint; otherwise creates a new one. If projectID is provided, automatically adds the sprint to the project (atomic operation). |
| create_or_update_releaseA | Creates a new release or updates an existing release in Plan. If releaseDbid is provided, updates the release; otherwise creates a new one. If projectID is provided, automatically adds the release to the project (atomic operation). |
| get_available_workitem_typesC | Get the available workitem types for a project in Plan for a given application |
| create_work_itemC | Creates a new work item in Plan |
| get_work_itemsC | Retrieves all work items for a given application, can filter by work item type and specific owner |
| delete_work_itemC | Deletes a work item in Plan |
| update_work_itemA | Updates fields of an existing work item. Provide the fields you want to update with their new values. IMPORTANT: When assigning a Sprint to a work item, the work item MUST first have the corresponding Release assigned to its PlannedRelease field. You cannot assign a sprint to a work item unless that work item is already part of the release that owns the sprint. Always update PlannedRelease before updating Sprint field. |
| get_applicationsB | Retrieves all applications from the Plan system |
| get_available_statesA | Gets the state transition matrix for work items in Plan for a given application, showing available transitions/actions |
| change_work_item_stateB | Changes the state of a work item in Plan using a two-step process (movement request + commit) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Each tool has a clearly distinct purpose targeting specific resources and actions in the Plan system. For example, create_work_item, update_work_item, and delete_work_item handle different lifecycle stages, while get_available_components, get_available_projects, and get_available_states retrieve distinct metadata types. There is no overlap or ambiguity in functionality.
All tool names follow a consistent verb_noun pattern with snake_case, such as create_work_item, get_applications, and update_work_item. The naming is predictable and uniform across all 14 tools, making it easy for agents to understand and select the correct tool.
With 14 tools, the server is well-scoped for a DevOps Plan domain, covering work items, releases, sprints, applications, and metadata. Each tool serves a specific, necessary function without redundancy, aligning with typical tool counts for such systems (e.g., 3-15 tools).
The tool set provides complete CRUD and lifecycle coverage for work items (create, get, update, delete, state changes), releases and sprints (create/update, get), and essential metadata (applications, projects, components, states, types). There are no obvious gaps; agents can perform all core DevOps planning operations without dead ends.