Skip to main content
Glama
kunwarVivek

mcp-github-project-manager

by kunwarVivek

AI Planning

ai_plan

Plan sprints by calculating capacity, prioritizing backlogs, assessing risk, suggesting composition, and generating roadmaps or visualizations for GitHub projects.

Instructions

AI-powered planning: calculate capacity, prioritize backlog, assess risk, suggest sprint composition, generate roadmaps and visualizations. Use the action field to select the operation.

Input Schema

NameRequiredDescriptionDefault
actionYesThe AI planning operation to perform
agentIdNo
roadmapNo
capacityNo
velocityNo
projectIdNo
autoCreateNogenerate_roadmap only: create the milestones in GitHub and assign them to the project's issues. Requires projectId.
constraintsNo
sprintItemsNo
teamMembersNo
backlogItemsNo
dependenciesNo
projectTitleNo
requirementsNo
businessGoalsNo
riskToleranceNo
sprintCapacityNo
businessContextNo
targetMilestonesNo
historicalSprintsNo
projectDescriptionNo
sprintDurationDaysNo
sprintDurationWeeksNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds little beyond the purpose: it does not disclose that generate_roadmap with autoCreate can create milestones in GitHub, nor does it clarify which actions are purely analytical versus side-effecting.

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 two sentences and front-loads the tool's scope before the action-selection note. It is efficient with no filler, though the operation list is a dense run-on and could be structured by action.

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 six-action tool with 23 parameters, no output schema, and very low schema description coverage, the description is insufficient. It enumerates the operations but omits per-action parameter requirements, side effects, and what each operation returns.

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?

There are 23 parameters with only 9% schema description coverage, and the description mentions only the `action` field, which is already documented by the schema enum. It does not explain the many nested objects, required fields per action, or how parameters like `velocity`, `constraints`, `historicalSprints`, and `autoCreate` affect each operation.

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 names a specific resource, AI planning, and enumerates six concrete operations: capacity calculation, backlog prioritization, risk assessment, sprint composition, roadmap generation, and visualization. This lets an agent distinguish it from general-purpose siblings such as ai_generate and ai_analyze, though it does not explicitly compare itself to them.

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 guidance is 'Use the `action` field to select the operation,' which explains invocation mechanics rather than when to choose this tool or a specific action. It does not state when to use ai_plan versus ai_generate/ai_analyze, nor which action fits which planning scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.