Loading ToolBench

Reading the current corpus…

Sprint-Pulse MCP server · D · ToolBench

← Browse

Sprint-Pulse

github.com/Yash-srivastav16/Sprint-Pulse

Model Context Protocol server exposing SprintPulse risk + standup tools to any MCP-capable agent.

2026-07-28+STDIO6 tools

57/100

Definition Quality78

Protocol Readiness50

Supportability28

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

SprintPulse MCP server has well-structured tool definitions with clear action verbs and detailed descriptions (avg 150+ chars). All 6 tools have input schemas with typed properties and required fields. However, parameter descriptions are inconsistent, some parameters lack descriptions entirely (e.g., 'sprintId' in get_project_risk has no description), and output schemas are not documented. Error handling is minimal; tools do not guide recovery or categorize errors. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata. The server follows basic MCP patterns but lacks production-grade polish in parameter documentation and error guidance.

Tools (6)

get_member_healthread onlyauthsource verified78/100

Get a single team member's pulse: health score, risk flags (BURNOUT_SIGNAL, BLOCKER_UNRESOLVED, etc.), recent standups, and supporting evidence. Use this to drill into why a project's risk score is what it is.

get_project_riskread onlyauthsource verified80/100

Get the current risk picture for a SprintPulse project: team health score, top risks, P1 alert state, and recommended next actions. Use this when an agent needs to decide if a project needs intervention.

parse_transcriptwriteauthsource verified77/100

Parse a meeting transcript (WebVTT or plain Speaker: text) into structured per-speaker standups and persist them. Returns the parsed entries plus AI-derived risk analysis for the sprint. Use this when an agent has captured a meeting and wants to land standups + risk update in one call.

run_member_pr_reviewread onlyauthsource verified75/100

Run SprintPulse's AI PR review on a member's recent commits/PRs. Returns review notes, complexity flags, and recommended follow-ups. Use this when an agent is helping triage code-review pressure across the team.

send_app_notificationwriteauthsource verified82/100

Create an in-app SprintPulse notification/action item for a project member. Use this when an agent has identified a follow-up and needs it to appear inside SprintPulse instead of sending email or chat.

Issues (5)

HIGHtool-description ↗

Parameter descriptions missing or incomplete. 'sprintId' in get_project_risk, get_member_health, run_member_pr_review, and send_app_notification lack descriptions. LLMs cannot infer when to pass optional parameters without explicit guidance.

get_project_riskget_member_healthrun_member_pr_reviewsend_app_notification

HIGHresponse-shaper ↗

Output schemas not documented. Tools return JSON responses but no schema is visible in source code. LLMs cannot plan downstream calls or extract fields without knowing response structure.

get_project_riskget_member_healthsubmit_standupparse_transcriptrun_member_pr_reviewsend_app_notification

MEDIUMtool-annotations ↗

No tool annotations despite clear risk classifications. Tools marked READ_ONLY or WRITE in metadata but not exposed via readOnlyHint/destructiveHint in schema. Agents cannot infer safety/idempotency from tool definitions alone.

submit_standup

Recommendations

Add descriptions to all optional parameters. For 'sprintId': 'Optional sprint ID; if omitted, defaults to the currently active sprint for the project.' For 'severity' and 'kind' enums in send_app_notification, expand descriptions beyond the enum list.
Document output schemas for all tools. Create a schema definition (e.g., in a separate .ts file or JSDoc) showing the structure of each tool's response, including field types and meanings. Example: get_project_risk returns {teamHealthScore: number, topRisks: Risk[], p1AlertState: boolean, recommendedActions: string[]}.
Add tool annotations to the inputSchema. For WRITE tools (submit_standup, parse_transcript, send_app_notification), add 'destructiveHint: true' or 'idempotentHint: true' to the schema. For READ_ONLY tools, add 'readOnlyHint: true'. This enables agents to reason about side effects.
Implement error handling with recovery guidance. Wrap HTTP calls in try-catch; return structured errors like {error: 'user_not_found', message: 'Team member not found. Try search_members() with a partial name.', retryable: false}. Categorize errors as retryable, user-fixable, or fatal.
Add validation and constraints to parameters. For 'blockers' in submit_standup, validate that it is either a non-empty string or exactly 'No blocker.' Return a clear error if neither. For 'severity' and 'kind', validate against the enum and reject invalid values with a helpful message.

Score history

Overall score trend

First recorded score · v2 rubric

57/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	57	2026-07-28+	v2