refactor: replace dedicated epic tools with work-item-type-based approach and add server instructions#149
Conversation
📝 WalkthroughWalkthroughDedicated epic MCP tools ( ChangesEpic-to-Work-Item-Type Migration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/test_integration.py`:
- Line 199: The list endpoints in the plane_mcp/tools module are returning
pagination metadata (dicts) instead of just the list payload, which causes the
test code to incorrectly attempt to access a ["results"] key on what should
already be a list. Modify all list endpoints to return only `response.results`
(the list) instead of the full response object with pagination metadata, then
update line 199 in the test to remove the `["results"]` indexing since
`extract_result(epics_result)` will already be the list. This ensures
consistency where `extract_result()` on list endpoints returns the list directly
without needing additional dict key access.
- Around line 138-157: The epic-type resolution logic has two issues: first, it
checks if workspace_types is non-empty to decide whether to create at workspace
or project scope, but this doesn't properly handle the case when workspace_types
exists but is empty; second, when creating a workspace-level Epic type on line
146, it does not first check whether an "Epic" type already exists in
workspace_types, which can create duplicates. Fix this by searching
workspace_types for an existing "Epic" type using the same pattern as the
project_types search on line 141, and only create a new workspace Epic if one
doesn't already exist. Then reconsider the mode-selection logic to ensure it
correctly distinguishes between valid creation paths and doesn't fall through to
project-scoped creation when workspace-level creation is appropriate.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 199a60b3-9c34-4b48-b21c-a6ff4803a12a
📒 Files selected for processing (9)
README.mdplane_mcp/instructions.pyplane_mcp/server.pyplane_mcp/tools/__init__.pyplane_mcp/tools/epics.pyplane_mcp/tools/initiatives.pyplane_mcp/tools/projects.pyplane_mcp/tools/work_item_types.pytests/test_integration.py
💤 Files with no reviewable changes (3)
- plane_mcp/tools/epics.py
- plane_mcp/tools/projects.py
- plane_mcp/tools/init.py
Description
This PR removes epic module and replaces it with:
Server Instructions (
instructions.py)Sent to MCP clients at session initialization via FastMCP's
instructionsparameter. Three sections guide the LLM:Work item type scoping — when to use
resolve_work_item_typeversus manual tools.Epics — how to create, list, nest, and delete epics using generic work item tools.
Initiatives — toggle-aware fallback behavior:
"Initiative"work item type when the feature is disabled.import_work_item_types_to_projectExposed as a standalone tool for cases where callers need explicit control over the import step.
Initiative Toggle Guard
create_initiativenow raises aToolErrorwhen the workspace initiatives feature is disabled. The error message contains guidance directing the LLM to the fallback flow.Type of Change
Summary by CodeRabbit
Release Notes
Documentation
New Features
Changes