Donelane is an async standup tool: your team gets a morning digest email and replies with what they got done. This MCP server puts your agents in that same loop.
Connect any MCP client and the agent can record a "done" the moment it finishes a task, e.g. "Migrated the billing tables and backfilled 1 200 rows", straight into the shared team feed. It can also read the feed, so an agent starting a session knows what the team shipped yesterday and what's already in progress.
Scored across 3 tools
Each tool targets a distinct concern: reading dones, creating dones, and identifying the account/team context. There is no overlap or ambiguity between them.
list_dones and post_done follow a clear verb_noun pattern, while whoami deviates slightly. The deviation is minor and conventional, so the set remains predictable and readable.
Three tools is well-scoped for a focused Done journaling server. Each tool earns its place and there is no bloat.
The core workflow of listing dones, posting a done, and identifying the acting account/teams is covered. Minor gaps exist such as no update/delete or individual done retrieval, but they are not critical for the server's apparent purpose.
Recent dones, either the signed-in person's own journal or one of their teams.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back to read. 1 to 30, default 7. | |
| team | No | Team slug. Omit for the personal journal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation and mentions scope, but does not state that it is read-only, whether team membership is required, what happens with an invalid team slug, or how results are ordered/limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler. The most important scoping distinction (personal vs. team) is presented immediately and clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two optional parameters and complete schema descriptions, this is mostly adequate. However, with no annotations and no output schema, the description leaves out behavioral details such as return format, sorting, and access requirements, which an agent would benefit from knowing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving the baseline of 3. The description adds genuine value by explaining the team parameter's semantics: omitting it selects the personal journal while providing a team slug selects that team's journal, which is not fully explicit in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The tool clearly identifies its resource ('dones') and adds a scope distinction ('own journal or one of their teams'), which helps differentiate it from the sibling tools. However, the description is a noun phrase rather than a direct verb+resource statement, relying on the title to convey the 'list' action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the main usage choice: personal journal vs. a specific team. It does not explicitly state when to prefer this tool over post_done or whoami, though the read-oriented nature of 'dones' makes that mostly inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record something that was finished. Posts as the connected user and is marked as agent-written.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | Team slug to post into. Omit to post to the personal journal. | |
| text | Yes | What was finished. One line per done; a line starting with "[ ]" becomes a goal instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states two important behaviors: the post is attributed to the connected user and will be marked as agent-written. This goes beyond the schema and helps the agent understand the side effect and provenance of the action, though it does not discuss reversibility or visibility scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is front-loaded, followed immediately by the most relevant behavioral details. Every word adds value, and the structure makes it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description provides enough context to invoke it correctly: what it records, under whose identity, and how it will be labeled. It lacks a mention of return behavior, but that is not critical given the tool's simplicity and the schema's full parameter coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (team and text). The tool description adds no additional parameter-level meaning or examples. The baseline of 3 is appropriate since the schema handles parameter semantics completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Record') and a clear resource ('something that was finished'), making the tool's purpose instantly recognizable. It also includes distinctive details about posting as the connected user and agent-written marking, separating it from siblings like list_dones. No ambiguity remains about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this is the tool to use for recording finished work, but it does not explicitly contrast it with list_dones or whoami, nor mention exclusions or conditions. An agent can infer usage from the tool's name and purpose, but that inference is not explicitly supported by the description text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Donelane account this connection acts as, and the teams it belongs to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the core behavior (reporting the connection's account and teams) but does not explicitly state that it is read-only, what authentication context is required, or how errors are handled. For a whoami-style operation the essential behavior is stated, but additional guarantees would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the output in a compact phrase. Every word earns its place, with no extraneous detail or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description provides the essential information (account and teams), which is enough to select and call a parameterless identity tool. It stops short of describing the response format or team representation, but that is not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description adds no parameter details because none are needed. Per the baseline for zero-parameter tools, this dimension is satisfying.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states what the tool provides: the Donelane account and the teams it belongs to. Though it lacks an explicit verb like 'returns', the noun phrase clearly identifies the resource, and it is distinct from sibling tools list_dones and post_done, which operate on dones rather than identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus list_dones or post_done. The description implies the scenario (needing connection identity and team membership), but an agent must infer it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_donespost_donewhoami
Add one secure layer between your agents and this server.