Loading ToolBench
Model Context Protocol Server for Cursor IDE Integration. Exposes Pulse CLI functions as MCP Tools for controlled agentic development loops with guardrails, checkpoints, and escalation.
The Pulse MCP server presents a domain-specific tool set for AI-assisted development guardrails, but exhibits significant definition quality gaps. While tool names are reasonably clear (all start with 'pulse_' prefix + action verb), most parameter descriptions are minimal and several tools lack proper input schema documentation. Output schemas are not documented anywhere in the provided source. Error handling guidance is absent. The server targets a specialized use case (Cursor agent guardrails) but lacks the rigor expected of production-grade agent tools.
Git Checkpoint: Check status, detect red flags, optional tests/commit
Create correction prompt when agent goes off track
Check safeguards + red flags (secrets, deletes, loops, scope)
Create escalation: Prepare problem for external model (GPT-5/Claude/Opus)
Document learnings and patterns from development session
Set development profile/layer (Concept, Build, Escalation)
Create review checklist for code changes
Run custom Pulse actions or templates
pulse_start, pulse_learn, and pulse_review accept no input parameters (empty {} schemas) but lack documentation explaining what context they use or what they return. Without input schemas or output documentation, LLMs cannot reason about preconditions or downstream data availability.
No output schemas are documented for any tool. LLMs need to know what fields to expect in responses to plan downstream calls and extract required data. Without documented return types, agents cannot reliably chain tools together.
pulse_run has ambiguous naming and vague parameters. 'action' and 'template' are free-form strings with no enum constraints or documentation of valid values. LLMs will hallucinate actions that do not exist. Should provide enum list or discovery tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Start a new task with Pulse context and constraints
Get current Pulse status: project state, last checkpoint time, git info
No error handling guidance. Tools that execute state changes (pulse_checkpoint, pulse_escalate, pulse_correct, pulse_learn, pulse_profile) lack documentation about failure modes, retryability, or recovery steps. LLMs have no guidance on what to do if a tool fails.
pulse_escalate and pulse_correct descriptions do not clarify idempotency or side effects. These tools create escalation packages and correction prompts (artifacts with side effects), but lack confirmation or dry-run capability. Agents could accidentally create duplicate escalations on retry.
pulse_checkpoint 'message' parameter (optional string for git commit message) lacks format guidance or validation rules. What happens if the message is too long or contains special characters? Should document git commit message constraints.
pulse_doctor 'hook' enum accepts 'pre-commit', 'pre-push', 'none' but does not explain what each mode changes about behavior. Descriptions should clarify that 'pre-commit' mode runs less intensive checks, etc.
pulse_escalate accepts 'include' array (glob patterns) and 'autoInclude' boolean, but relationship between them is not documented. If both are set, what takes precedence? Undocumented parameter relationships cause misuse.