planeshift-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PLANESHIFT_ENV | No | Set to `development` to use a local Planeshift (http://localhost:3000) with its own credentials file instead of production (equivalent to passing --dev). | |
| PLANESHIFT_URL | No | The URL of your Planeshift instance; overrides the saved credentials when used together with PLANESHIFT_TOKEN. | |
| PLANESHIFT_TOKEN | No | A Planeshift API token (create one on the API tokens page). Used instead of the credentials saved by `planeshift-mcp login` and takes precedence over saved credentials. |
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 |
|---|---|
| list_projectsA | List the Planeshift projects of the current user. Use it to find a project id. |
| get_timelineA | Read the timeline of a project (notes, meetings and actions), newest first. Pass |
| add_noteC | Add a note to the timeline of a project. |
| add_meetingB | Record a meeting on the timeline of a project: what was discussed and decided. |
| add_todo_actionB | Add an action (a to-do item) to a project. It starts as pending. |
| add_important_linkB | Add a reference (an important link, like a dashboard or a doc) to a project. |
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 6 tools
The tools split cleanly into two reads (list_projects, get_timeline) and four distinct add_* writers targeting different artifacts (note, meeting, action, link). The only mild overlap is add_note vs add_meeting, since both append to the same timeline, but the descriptions clarify that meetings capture discussion/decisions.
All names are snake_case verb_noun (list_projects, get_timeline, add_note...), which is predictable and readable. Minor deviation: add_todo_action and add_important_link insert extra modifiers, making the noun phrase less uniform than the others.
Six tools is well-scoped for a project timeline server: two read operations plus four creation operations covering the domain's core entities. Every tool earns its place with no filler.
The surface covers listing, reading, and appending, but there is no way to update or delete notes/meetings/links, and notably no way to mark a to-do action as completed despite actions starting as pending. These gaps will force agents into dead ends for a to-do workflow.