Loading ToolBench
Exposes the Pulse knowledge base as MCP tools for AI coding agents. Any MCP-compatible tool (Claude Code, Cursor, etc.) can query and contribute to the team's operational memory.
Pulse MCP has well-structured tool definitions with clear, action-oriented names (pulse_search, pulse_context, pulse_file_context, pulse_create) and comprehensive descriptions (150-250 chars each). All tools have documented input schemas with types, enums, and constraints. However, output schemas are not documented in the source code provided, and error handling guidance is absent. The pulse_create tool accepts optional session_id and device parameters but lacks security guidance on sensitive data handling. Tool descriptions are LLM-optimized and explain WHEN to use each tool, meeting pattern:tool-description standards. Parameter descriptions are present and specific (e.g., 'Search terms (all terms must match)', 'Filter by insight kind'). Composition is clean: four single-responsibility tools with clear chaining (search → context → create). Missing: documented return types, error recovery guidance, and validation rules for structured data in pulse_create.
Get relevant context from the knowledge base for a topic or question. Uses semantic search to find the most relevant insights, even if exact words don't match. Use this when starting work on a topic to understand past decisions and avoid known dead-ends.
Record a new insight in the team's knowledge base. Use this when you make a technical decision, discover a dead-end, identify a reusable pattern, complete a milestone, or capture a business requirement/domain constraint that drove a technical choice. Insights are created as drafts and can be published later.
Get all insights related to a specific file. Use this when you're about to modify a file to understand the decisions, patterns, and dead-ends associated with it.
Search the team's knowledge base for insights — decisions, dead-ends, patterns, and progress. Use this before making technical decisions or when you encounter a problem that may have been solved before.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields to expect from pulse_search, pulse_context, pulse_file_context, or pulse_create responses.
No error handling guidance. Tools lack recovery hints (e.g., 'If query returns no results, try pulse_context with broader terms'). Agents cannot self-correct on failures.
pulse_create accepts optional session_id and device parameters but lacks security guidance. No documentation that these should not contain secrets or PII, and no audit trail pattern documented.
pulse_create's 'structured' parameter is an untyped object with kind-specific schemas documented only in the description text. LLMs cannot validate nested structures; this invites malformed input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
No pagination or result limits documented for pulse_search and pulse_context. If these return large result sets, context window exhaustion is possible.