mcp-dotpals
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| agents_nowA | What the coding agents on this computer (Claude Code, Codex, Cursor and others dotpals watches) are doing, or did in the last 2 hours, newest first: the project, whether each is working, waiting for you, finished or stopped, what it was asked, its latest step or result, and how its tests stand. dotpals reads this from what the agents actually did (their tool calls and the test output), not from what they said. Use it for "what are my agents doing?" and to find a session ID for the other tools. |
| test_statusA | Is the code really tested? How the tests stand in an agent session, from the test runs dotpals saw: passed or failed (read from the test output, with the counts, and why the last run failed), when, and whether code changed after the last run (stale) or was never tested. Only tests an agent ran count. Default: the newest session in this project. |
| ready_to_mergeA | Is an agent session's work ready to merge? The checks a reviewer would make, each ✓ or ✗: tests ran, after the last change, and passed (and not because the tests were changed); no failure left behind; nothing risky (force pushes, .env changes, recursive deletes…); the commit was tested. Pass |
| recapA | What agents actually did, request by request: what each was asked, one plain sentence on what it did (files changed, how the tests went, what it shipped), warnings worth a look (tests that passed only after they were changed, too), why its tests failed, and the files it changed. For a project (default: this one, the last 24 hours) or one session (all of it). |
| todayA | What the agents did today, for a standup or an end-of-day note: per agent, how many requests, files changed and test runs, then each request with what it was asked and one plain sentence on what it did, warnings worth a look (tests that passed only after they were changed, too) and why its tests failed. For a project (default: this one). |
| risky_stepsA | Risky things agents did, each with when, which agent and the command: force pushes, recursive deletes, git changes thrown away, dropped database tables, scripts piped from the internet, sudo and permission changes, force-stopped programs, changes to .env and other secret files, and the same command failing again and again. Use it for "did my agents do anything dangerous?" or before trusting their work. For a project (default: this one, the last 24 hours) or one session (all of it). |
| handoff_noteA | A hand-off note, so another agent (or a new session) can pick up where a session left off: the original ask and the last request, what was done with the evidence, the files it changed, how the tests stand (with the failure), what's left on its plan, what's risky and its last message. Markdown, ready to paste. Default: the newest session in this project. |
| check_my_workA | Call this before you tell the user your work is done. dotpals checks your own session in this project the way a reviewer would: did the tests run after your last change, did they pass (and why not), did you change the tests to make them pass, did anything fail and stay failing, did you do anything risky. It answers "Looks done" or says what to fix first. The evidence is what you actually ran, not what you remember. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools are distinguishable by domain facet (test status, activity, risk, handoff), but several overlap heavily: recap vs today both summarize what agents did, and ready_to_merge vs check_my_work both run near-identical reviewer checks (differing mainly in whose session is the default). test_status also overlaps with the test facets embedded in ready_to_merge and check_my_work, so an agent can plausibly misselect among these.
All names use snake_case, which is consistent, but the convention itself is mixed: some are question-style phrases (agents_now, ready_to_merge, check_my_work), some are bare nouns (recap, today), and others are noun_phrases (test_status, risky_steps, handoff_note). Readable but no single predictable verb_noun pattern.
Eight tools is well within a reasonable range for an agent-observability server and each maps to a plausible use case. Slightly heavy given that at least two pairs (recap/today, ready_to_merge/check_my_work) are near-duplicates, but overall the count is sensible.
The surface covers the domain well: per-session and per-project activity, test status, merge readiness, risk detection, handoff, and self-review. Coverage of the coding-agent lifecycle is broad; minor gaps (e.g. no explicit session-listing or time-range customization beyond defaults) are workable.