Loading ToolBench
MCP server for project management, work package planning, issue tracking, feature requests, and project memory management
PinkRooster MCP demonstrates solid definition quality with comprehensive tool coverage (15 tools) and detailed descriptions. All tools have descriptions (50-300+ chars, well above 20-char minimum). Input schemas are present with typed parameters and enums. However, output schemas are not explicitly documented in the provided source, and some parameter descriptions lack actionable constraints (e.g., enum values not listed inline). Error handling guidance is present but inconsistent across tools. Tool naming follows verb_noun convention well (delete_entity, create_or_update_issue, manage_dependency). Composition is strong, tools are single-responsibility and chain well (e.g., get_feature_requests → get_feature_request_details). Security considerations are documented (e.g., 'Does NOT create audit entries', 'Circular dependencies rejected'). Main gaps: output schemas not visible, some enum values not enumerated in descriptions, and missing dry-run/confirmation patterns for destructive operations.
Creates a new feature request or updates an existing one. Returns OperationResult with the FR ID (e.g. 'proj-1-fr-3'). To create: provide projectId and required fields (name, description, category). To update: provide projectId and featureRequestId, plus any fields to change (PATCH semantics: null = keep current). Feature requests track ideas and enhancements — use create_or_update_issue for bugs. Does NOT manage user stories after creation — use manage_user_stories for that.
Creates a new issue or updates an existing one. To create: provide projectId and required fields (name, description, issueType, severity). To update: provide projectId and issueId, plus any fields to change (PATCH semantics: null = keep current). Returns OperationResult with the issue ID (e.g. 'proj-1-issue-5'). Issues track bugs and problems — use create_or_update_work_package for planned work. Does NOT delete issues — use delete_entity for that.
Creates a new project memory or merges into an existing one with the same name. Returns OperationResult with the memory ID and whether a merge occurred (wasMerged). If a memory with the given name already exists, the new content is appended (separated by '---') and tags are merged (union, deduplicated). Does NOT replace existing content on name match — to fully replace, use delete_memory first then create. Use this for storing project-specific knowledge, decisions, patterns, and context.
Creates a new phase or updates an existing one. Returns OperationResult with the phase ID (e.g. 'proj-1-wp-2-phase-1') and any cascade state changes. PREFERRED for batch task operations: pass the 'tasks' parameter to create or update multiple tasks in one call instead of calling create_or_update_task repeatedly. To create: provide workPackageId and name. To update: provide phaseId plus fields to change. For creating a full WP with phases and tasks at once, use scaffold_work_package instead.
Output schemas not documented in source. Tools return OperationResult, but field structure, types, and chaining IDs not visible. LLMs cannot plan downstream calls without knowing response shape.
Enum values not listed inline in parameter descriptions. E.g., 'category' param for create_or_update_feature_request says 'Feature category' but does not enumerate valid values. LLMs must infer from schema, wasting reasoning cycles.
Destructive operations (delete_entity, delete_memory) lack dry-run or confirmation step. Agents can permanently delete cascading entities without a safety gate. No mention of undo capability or recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Permanently deletes an entity. Returns OperationResult confirming deletion. Work package deletion cascades to all its phases and tasks. Phase deletion cascades to all its tasks. Issue/FR deletion clears WP links (WPs are NOT deleted). Does NOT create audit entries for the deletion itself. This action cannot be undone.
Permanently deletes a project memory by its ID. This action cannot be undone. Does NOT affect other entities — memories are standalone. Returns OperationResult confirming deletion. Use list_memories to verify the correct ID before deleting.
Returns all fields for a single feature request including status timestamps, user stories, attachments, and linked work packages. Does NOT include audit history. For listing multiple feature requests, use get_feature_requests instead.
Returns a compact list of feature requests (ID, name, status, priority, category) for a project. Does NOT include user stories, business value, or linked work packages. For full data, use get_feature_request_details instead. For feature request counts by category, use get_project_status.
Returns all fields for a single issue including state timestamps, attachments, and linked work packages. Does NOT include audit history. For listing multiple issues, use get_issue_overview instead.
Returns a compact list of issues (ID, name, state, priority, severity) for a project. Does NOT include detailed fields (steps to reproduce, stack trace, attachments, linked WPs). For full issue data, use get_issue_details instead. For issue counts by category, use get_project_status.
Returns the full content, metadata, and tags for a single project memory. Content may be long if the memory has been merged multiple times (content is appended with '---' separators on each upsert-by-name). Use list_memories to find memory IDs first.
Returns a compact list of project memories (ID, name, tags, updatedAt). Supports filtering by name pattern (case-insensitive substring match) and/or tag. For full memory content, use get_memory_details with the memory ID.
Adds or removes a dependency between work packages or between tasks. Entity type is auto-detected from the ID format: 'proj-N-wp-N' for work packages, 'proj-N-wp-N-task-N' for tasks. Both IDs must be the same type (both WP or both task) — does NOT support cross-type dependencies (WP-to-Task or Task-to-WP). When adding: if the blocker is non-terminal, the dependent auto-transitions to Blocked. When the blocker completes, dependents auto-unblock. Returns OperationResult with stateChanges showing any automatic state transitions. Circular dependencies are rejected with an error.
Add, update, or remove a user story on a feature request. Returns OperationResult with the FR ID and updated story count. Each user story has structured fields: role, goal, benefit (maps to 'As a [role], I want [goal], so that [benefit]'). Use index (0-based) to target a specific story for Update or Remove.
Records verification results for acceptance criteria on a phase. Matches criteria by name (case-insensitive) and sets VerificationResult + VerifiedAt timestamp. Returns OperationResult listing matched criteria. Safe to call multiple times — re-verification updates the result and timestamp. Does NOT create new criteria — use create_or_update_phase with acceptanceCriteria to define them first.
Error handling guidance incomplete. Tools mention rejection of circular dependencies and cascade behavior, but do not specify error response format, retryability, or recovery steps for common failures (e.g., entity not found, permission denied).
Pagination not visible for list tools (get_feature_requests, get_issue_overview, list_memories). No limit, offset, or cursor parameters documented. Large result sets could exhaust context window.