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). |
| report_cardA | A report card comparing the agents side by side over a period (default: the last 7 days, every project): requests, how many that changed code were tested after the last change and passed, how many weren't tested, how many tries a failure took to fix, tests changed to make them pass, things a summary claimed that didn't happen, requests that went in circles, tokens per request and time spent. Read from what the agents did, not what they said. A Markdown table. Pass |
| briefA | The morning brief or the weekly recap, per project: what the agents did (requests, files changed, tokens), what's unfinished (a request cut off, given up, left with failing tests or a question for you), what's failing now (tests failing, or code changed and not tested since), and what's worth a check (tests changed to pass, claims that didn't happen). |
| 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 10 tools
Several tools overlap heavily on reporting agent activity: recap, today, brief, and report_card all summarize what agents did, differing mainly by period or scope. ready_to_merge, check_my_work, and test_status also overlap on test/readiness review. The descriptions clarify defaults and distinctions, but an agent could reasonably misselect for broad questions like 'what did my agents do?'
All names are lowercase snake_case and readable, but the set mixes single nouns (recap, brief, today), noun phrases (report_card, test_status, handoff_note, risky_steps), and verb phrases (ready_to_merge, check_my_work). There is no consistent verb_noun pattern to predict new or related tool names.
10 tools is a reasonable size for an agent-observability server, and most cover distinct artifacts like current activity, risks, tests, handoff, and readiness. However, the four summary/report tools create notable redundancy, slightly inflating the set beyond what the domain strictly needs.
The surface covers the core observability lifecycle well: live agent status, multiple recaps, readiness checks, test status, risky actions, and handoff notes. A minor gap is the lack of a tool to list past sessions or resolve a session ID older than agents_now's 2-hour window, which limits practical use of session-scoped tools.