central-mcp

Overview Schema Source Related Servers Discussions Admin

project_pulse

Retrieve a project's current state directly from its repository—git status, commits, open PRs, dispatches, and sessions—to see what changed and what's next.

Instructions

What actually happened in a project, where it stands, what's live.

Use this when the user returns to a project after time away, asks "what's the state of X?", or before dispatching into a project you haven't touched this session. Unlike dispatch_history / orchestration_history — which only know about work that went through central-mcp — a pulse reads the repository itself, so direct commits, interactive agent sessions, and manual edits show up too.

Sections (each degrades independently, with a reason when unavailable — never assume a missing section means "nothing happened"):

git: branch, upstream ahead/behind, working-tree dirt with a bounded file sample, and the last commits commits.
dispatches: in-flight work, the last history outcomes with prompts and previews, and all-time success/failure counts. stale holds rows still marked running after hours — a crashed or restarted server never wrote their terminal state, so report them as unfinished, not as live work.
sessions: resumable agent conversations, when the project's agent has a session reader.
pull_requests: open PRs via gh. The only network call here — pass include_pr=False when sweeping many projects.

Nothing is stored: every call recomputes from source. Synthesize the result into a short narrative ("since your last visit … currently … next …") rather than reciting the fields back to the user.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`commits`	No
`history`	No
`include_pr`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.20.0Sep 21, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it does so thoroughly. It discloses that the tool performs no storage ('Nothing is stored: every call recomputes from source'), identifies the only network call (PRs via gh), and explains the `stale` field for crashed servers. It also instructs on handling missing sections with `reason`, preventing misinterpretation. This is comprehensive behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, usage guidance, and a section-by-section breakdown. It uses bullet points for readability and includes practical tips (e.g., include_pr=False for sweeps). While lengthy, it is information-dense and front-loaded with the core purpose, so every sentence contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple data sections, network call, degradation behavior), the description covers all critical aspects: what data each section provides, how to interpret stale entries, and the note about synthesizing output. Since an output schema exists, the return structure is likely covered there, so the description needn't repeat it. The description is complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters, and it does. It clarifies `commits` and `history` as counts for the last N items, explains `include_pr` with a performance tip, and the `name` parameter is self-evident. This adds value beyond the schema's bare types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line 'What actually happened in a project, where it stands, what's live' clearly defines the tool's function. It distinguishes itself from sibling tools like dispatch_history and orchestration_history by explicitly stating it reads the repository directly, covering direct commits and manual edits. This specificity ensures an agent understands its unique value.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit triggers: 'when the user returns to a project after time away, asks "what's the state of X?", or before dispatching into a project you haven't touched this session.' It also contrasts with alternative tools, clarifying when this tool is preferable because it captures work outside central-mcp. This is exemplary usage guidance.

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