Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Taskmaster MCP Server create a session for building a dashboard with tasks for setup, design, and deployment"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Taskmaster is an MCP server that runs design work as standard operating procedures. A request like "redesign the landing page" or "build an app that does X" becomes an end goal plus an ordered list of entries from a scope and situation matrix. For each entry, the agent writes a plan against that situation's SOP before any work starts, then Taskmaster hands it one SOP step at a time, with the design procedure's text for that step, until the goal is reached.
result = verify( behavior( layout( color( imagery( typography( research( components( order( content( question ) ) ) ) ) ) ) ) ) )The agent keeps no tasklist of its own. Taskmaster holds the plan and the sequence, gives the full procedure text when each step is reached, and resumes exactly where the work stopped after an interruption.
The procedure (design/process.txt) is the fixed rulebook for designing intentionally: one chain of steps 0–10, with the methods, rules, and order of the work. It is the same for every assignment.
The matrix (design/matrix.txt) is the selector. Every request maps to one or more entries, each a situation and a scope.
Situation SOPs (design/prompts/situations) set the working path through the procedure for each kind of job: a plain-language brief, then numbered SOP steps that each name the procedure step they work in.
Create builds from a brief.
Extend adds to an existing product and carries its design.
Redesign replaces what exists, using it as evidence.
Fix keeps what exists and repairs a specific problem at its cause.
Review inspects and recommends without changing anything.
Scope sheets (design/prompts/scopes) set how far the work reaches. The scopes form a ladder:
element → component → section → page → flow → product
shared-styles cuts across every rung.
Whether a unit should exist is decided by its parent, so an entry that finds its unit shouldn't exist escalates one rung.
Step 3 finds components rather than inventing them: name the job, look at how real products do it, then adapt the component they use.
Related MCP server: Agent Orchestrator MCP Server
Tool | Use |
| Read the selector before choosing entries |
| Request, end goal, and ordered entries ( |
| Write the plan, one item per SOP step, before any work; call again to revise it |
| Finish an SOP step with a short handoff; a trace step also takes |
| Finish a verify step: |
| End the entry and start the right one when the decision belongs to a parent scope or another situation |
| Read one procedure step in full |
| Re-issue the current step after an interruption |
| Add entries, such as a Fix after a Review |
| Entries, plan, position, and recorded results; with no |
| Close a session |
Every tool after start_session takes the session_id, so several conversations can run their own sessions at once against the same server.
The server also exposes the design files as resources under taskmaster://design/..., and a design prompt.
Requires uv and Python 3.10+.
uv sync
uv run taskmasterThat starts the server over stdio. For HTTP, use uv run taskmaster --transport streamable-http --port 8080; the endpoint is /mcp.
The same server also runs as a Netlify Function (netlify/) for use as a Claude custom connector at /mcp/<token>, with the token set in TASKMASTER_TOKEN.
Add this to a project's .mcp.json, with the path to this repository:
{
"mcpServers": {
"taskmaster": {
"command": "uv",
"args": ["run", "--project", "/path/to/taskmaster", "taskmaster"]
}
}
}Sessions are saved in .taskmaster/ in the folder the server starts from. Set TASKMASTER_STATE_DIR to change that, or TASKMASTER_DESIGN_DIR to use a different copy of the design files.
uv run pytest
npm testMIT
Add matrix entries to a session, after the current entry ('next') or at the end.
Use when the work needs another entry, such as a Fix or Redesign the user authorized after a Review.
| Name | Required | Description | Default |
|---|---|---|---|
| entries | Yes | Ordered matrix entries, each {situation, scope, goal} | |
| position | No | next | |
| session_id | Yes | The session_id start_session returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It states that entries are added after the current entry or at the end, but does not disclose authorization requirements, validation behavior, side effects on the session/current step, or reversibility for a mutation tool.
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?
Two sentences, front-loaded with purpose and then usage context. Every sentence earns its place and there is no redundant or filler text.
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?
It gives enough to invoke the tool with session_id, entries, and position, and the nested entry schema is descriptive. However, for a mutation tool with no annotations or output schema, the description lacks the behavioral contract an agent would need to understand consequences and constraints.
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 67%, and the schema already documents session_id and the nested entry fields. The description adds useful meaning for position ('next' after the current entry vs 'end') and gives an example of entry situations, but does not compensate for the remaining gaps around scope, goal, or entry ordering.
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 gives a specific verb ('Add') and resource ('matrix entries') scoped to a session, with insertion position ('after the current entry' or 'at the end'). It does not explicitly distinguish itself from siblings such as submit_plan, but the operation is clear enough for selection.
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?
It explicitly says when to use the tool: 'Use when the work needs another entry, such as a Fix or Redesign the user authorized after a Review.' That is clear usage context, though it provides no when-not conditions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finish the current SOP step (not a verify step) and receive the next one.
handoff: one to three sentences naming the actual result and how the next step uses it. responsible_step: required on a trace step — the procedure step (0–9) where the cause lies.
| Name | Required | Description | Default |
|---|---|---|---|
| handoff | No | ||
| session_id | Yes | The session_id start_session returned | |
| responsible_step | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool finishes a step and returns the next one, and it gives handoff and responsible_step constraints, but it omits permissions, reversibility, invalid-session/error behavior, and the full shape of the returned next step.
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 compact and front-loaded: purpose first, then two focused parameter notes. Every sentence adds usable guidance without repetition or filler.
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?
Given the lack of annotations and output schema, the description covers the core call semantics and the most important parameter constraints. It still leaves return-content details and error/side-effect behavior implicit, but it is sufficient for an agent to invoke the tool correctly in normal use.
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 only 33%, but the description compensates by explaining the two undocumented parameters: handoff should be one to three sentences naming the actual result and its use by the next step, and responsible_step is a procedure step 0–9 where the cause lies on a trace step. session_id is already described in the schema. Minor ambiguity remains around defaults and the conditional 'required' wording.
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 a specific verb and resource: 'Finish the current SOP step' and the immediate outcome 'receive the next one'. The parenthetical '(not a verify step)' distinguishes it from verify-related siblings such as report_verification, so an agent can identify its role without opening the schema.
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?
It clearly indicates when to use the tool: completing the current SOP step rather than a verify step. It does not explicitly name report_verification as the alternative or spell out prerequisites like start_session, but the exclusion is actionable enough for correct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-issue the current step with its SOP, plan item, procedure text, and earlier results. Use after an interruption or condensed context.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session_id start_session returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the returned payload (SOP, plan item, procedure text, earlier results), which is the key behavioral fact here. It doesn't state whether the call is side-effect free or whether re-issuing mutates step state, leaving a meaningful gap for a session-state tool.
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?
Two sentences, no filler, with the action and payload front-loaded and the usage condition second. Nothing is wasted.
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?
No output schema exists, and the description compensates by naming the four things that come back. Combined with a fully documented single parameter, an agent has what it needs; only the side-effect/idempotency profile is unstated.
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?
There is one parameter and schema description coverage is 100%, so the schema already explains that session_id is the value returned by start_session. The description adds nothing about the parameter, so the baseline of 3 applies.
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?
A specific verb ('re-issue') plus a specific resource ('the current step') and an enumeration of what is re-issued (SOP, plan item, procedure text, earlier results). It's clearly distinct from get_process_step or complete_step, though no sibling is named explicitly.
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?
'Use after an interruption or condensed context' gives a clear triggering condition, which is exactly the kind of routing hint an agent needs. It stops short of naming alternatives such as get_process_step, so it's a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a session. summary: what was delivered and any remaining limitations.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | No | ||
| session_id | Yes | The session_id start_session returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It mentions the summary content but does not disclose what ending a session actually does, whether it is irreversible, what happens to unfinished work, or what permissions are required.
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 definition is very short and front-loaded, with no wasted text. The terse 'summary:' phrasing is efficient, though it leaves important behavioral details unstated rather than clarifying them.
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 lifecycle mutation tool with no annotations and no output schema, the description is incomplete. It omits session-ending effects, prerequisites, and how the summary parameter is used operationally.
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 50%, with session_id already documented in the schema. The description adds useful meaning for the otherwise undocumented summary parameter by specifying it should cover delivered work and remaining limitations.
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 a clear verb and resource: 'End a session.' An agent can distinguish this from start_session by the verb, though the description does not explicitly name sibling alternatives or lifecycle context.
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 only usage guidance is implied by the word 'End' and the optional summary field. It does not say when ending is appropriate, whether prior steps must be completed, or how it relates to siblings such as complete_step or start_session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End the current entry because its decision belongs elsewhere, and start the right entry in its place.
Use when the unit should not exist or should move (escalate to its parent scope), or when a Fix needs the structure replaced (escalate to redesign). reason: what the step showed.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | ||
| to_scope | No | ||
| session_id | Yes | The session_id start_session returned | |
| to_situation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the current entry is ended and a replacement is started, which is important mutation context, but it does not cover irreversibility, permissions, side effects, or what happens to the ended entry.
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 short and front-loads the action before giving use conditions. Some phrasing such as 'the right entry' and 'the unit' is abstract, but there is little wasted text.
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?
Given four parameters, low schema coverage, no annotations, and no output schema, the definition is incomplete. It does not clarify the two optional enum parameters, the session lifecycle impact, or how this tool relates to siblings like complete_step or end_session.
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 only 25%, so the description needs to compensate. It explains reason only loosely as 'what the step showed' and hints at parent scope/redesign, but it does not explain to_scope, to_situation, or their enum choices.
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 a specific action: ending the current entry and starting a replacement entry. It is clearer than a tautology and distinguishes escalation reasons, but it does not name or differentiate sibling tools such as complete_step or end_session.
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?
It gives explicit use conditions: when the unit should not exist, should move to its parent scope, or when a Fix needs redesign. It lacks explicit when-not-to-use guidance or named alternatives among siblings, so it is strong but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the scope and situation matrix with its selector questions. Call this before start_session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears the full disclosure burden. "Return" implies a read with no side effects, and the required ordering before start_session is useful behavioral context, but nothing is said about idempotency, cost, or whether the matrix changes over time — gaps that a no-annotation tool arguably should fill.
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?
Two short sentences, front-loaded with what is returned and followed by the timing constraint. No filler.
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 params and no output schema, the description must orient the agent itself, and it does say the return includes selector questions. It stops short of describing the matrix's shape or how the selector questions should be answered, which would help without an output schema.
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 tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies no input is needed to fetch the matrix.
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?
Names a specific verb (Return) and resource (scope and situation matrix with its selector questions), so the agent knows exactly what comes back. It references start_session, but does not differentiate from other getters in the sibling list such as get_status or get_process_step.
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?
"Call this before start_session" gives explicit ordering guidance that an agent can act on. There is no when-not guidance or mention of other alternatives, but for a zero-arg getter the sequencing cue covers the main decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one procedure step from process.txt in full (0–10), for steps an SOP step names only by its Keep rule.
| Name | Required | Description | Default |
|---|---|---|---|
| step | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered before the description speaks. The description adds that the read is scoped to the current session's plan and returns the full text of one step, but says nothing about out-of-range indices, error behavior, or whether the return is plain text versus structured.
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 with no filler: verb, scope, and the indexing convention arrive immediately. Nothing is repeated from the schema or title.
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 one-parameter read tool with annotations covering safety, the definition is close to sufficient but has two holes an agent would hit: the 1-based index is given without a valid range or out-of-range behavior, and the relationship to get_plan (which presumably also contains steps) is unaddressed.
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?
With 0% schema description coverage, the description must carry the parameter's meaning — and it partially does by specifying '1-based index', which is real semantic value the bare integer schema lacks. It stops short of giving the valid range, whether index means ordinal position in the plan, or what happens for an invalid step number.
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?
Specific verb and resource: 'Fetch the full text of a single step' scoped to 'the current session's plan'. The word 'single' implicitly contrasts with bulk retrieval, but the description never names get_plan, so the distinction from the sibling that returns the whole plan is left to inference.
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?
No explicit when-to-use or when-not, and no mention of the obvious alternative (get_plan / get_step_all) even though it is a listed sibling. 'Current session's plan' only tells the agent which plan, not when to prefer this tool over fetching the whole plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a session's goal, entries, plan, position, and recorded results. Without a session_id, list recent sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a safe read of session state and discloses the list-vs-detail mode switch, but says nothing about permissions, result volume, ordering of recent sessions, or how much history is returned.
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?
Two sentences, no filler, with the primary behavior front-loaded and the alternative mode as a second short clause.
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 one optional parameter and no output schema, the description adequately covers return values by naming the facets returned. Only ordering/pagination details for the recent-sessions mode are absent, a minor gap for this complexity level.
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 0% and the parameter has a bare default of empty string, but the description compensates by explaining that an omitted session_id switches the tool into a recent-sessions listing mode. That is the exact semantic an agent needs beyond the schema.
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?
States a specific verb (show) and resource (a session's status), and enumerates the returned facets (goal, entries, plan, position, results), which separates it from action-oriented siblings like start_session and end_session. It does not explicitly distinguish itself from current_step or get_process_step, which also read session state.
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 gives clear mode guidance for its single parameter ('Without a session_id, list recent sessions'), which is genuinely useful. However, it offers no guidance on when to prefer this aggregation tool over narrower siblings such as current_step or get_matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finish a verify step.
outcome: 'done', or the number (0–9) of the procedure step responsible for the earliest discrepancy. findings: each discrepancy with its evidence and responsible step, or what was checked when done.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | ||
| findings | No | ||
| session_id | Yes | The session_id start_session returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does explain that outcome can be 'done' or a step number indicating responsibility for the earliest discrepancy, and that findings should capture each discrepancy with evidence or what was checked when done. However, it omits what finishing the step does to the session, whether it triggers downstream effects, and whether the action is reversible.
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 short and front-loads the core action before detailing the two parameters. The line-broken format with 'outcome:' and 'findings:' is slightly unconventional but not wasteful, and every sentence contributes useful information.
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?
Given no annotations, no output schema, and only 33% schema description coverage, the description should do more to explain side effects and process context. It does not clarify how this tool relates to complete_step, current_step, or end_session, nor does it state what happens to the verification session after the report is submitted.
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 only 33%, so the description must compensate. It adds meaningful semantics for outcome by defining the 'done' value and the 0–9 step-number convention, and for findings by explaining the expected content for discrepancies and completed checks. Only session_id lacks added meaning, but the schema already documents it as the ID returned by start_session.
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 clearly states a specific action: finish a verify step. It also explains what outcome and findings represent, so the agent can understand the immediate purpose. However, it does not distinguish this tool from sibling complete_step, leaving ambiguity about why one would finish a verification via this tool versus a generic step-completion tool.
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 the tool is used to conclude a verify step, but gives no explicit guidance on when to call it versus complete_step, escalate, or end_session. There is no mention of prerequisites, alternatives, or conditions that select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a design session and receive its session_id, the working method, and the first entry's SOP.
request: the user's words. end_goal: the observable condition that holds when the work is complete. entries: the matrix entries in the order they will run, worked backward from the end goal. task_conditions: device, platform, audience, existing identity, available assets, stage of completion, and whether identity is open to change.
| Name | Required | Description | Default |
|---|---|---|---|
| entries | Yes | Ordered matrix entries, each {situation, scope, goal} | |
| request | Yes | ||
| end_goal | Yes | ||
| task_conditions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden. It usefully discloses the return payload (session_id, working method, first entry's SOP), but says nothing about the stateful side effects of creating a session, whether it can be called twice, or what happens on duplicate invocation.
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 lead sentence covering purpose and return, then a tight per-parameter gloss with no filler. Front-loaded and every clause carries information.
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 stateful session-creating tool with no annotations and no output schema, the description covers inputs and returns but omits the life cycle: which sibling to call next, whether the session expires, or how add_entries/end_session relate to it.
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 only 25% — request and end_goal are entirely undocumented in the schema — and the description compensates by defining all four parameters, including that entries must be ordered and derived backward from end_goal and what task_conditions should enumerate. It adds real meaning the schema lacks.
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?
States a specific verb and resource ("Start a design session") and adds what comes back (session_id, working method, first entry's SOP). It does not name any sibling tool, but the start/end lineage against end_session and the read-only siblings is inferable from the verb.
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?
Usage is only implied: a tool that mints a session_id is obviously the entry point before current_step, complete_step, or submit_plan, but the description never says so or names when not to use it (e.g., use add_entries to extend an existing session).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write or revise the plan for the current entry: one item per SOP step, in order. The first plan starts the work.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | One item per SOP step, in order: the specific work, the questions to answer, and the result that shows the step is complete | |
| session_id | Yes | The session_id start_session returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose one meaningful trait — that the first plan initiates work, implying a state transition — but it does not say whether a revision replaces or appends to the prior plan, whether ordering/step count is validated, or what happens on failure.
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?
Two short sentences with zero filler, the primary action front-loaded and the consequential behavioral detail ('first plan starts the work') placed last for emphasis.
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 two-parameter tool with full schema coverage and no output schema, the description covers purpose, format, and the key side effect. The only material omission is revise semantics — whether a resubmission overwrites the existing plan.
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 both parameters are already documented, including the per-step content requirement. The description restates the ordering constraint from the schema but adds no new syntax, cardinality, or format guidance, so the baseline 3 applies.
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 names a specific verb pair (write or revise) and a precise resource (the plan for the current entry), plus the format constraint of one item per SOP step. It does not explicitly distinguish itself from siblings like complete_step or current_step, but an agent can tell this is the planning-submission tool.
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?
Usage is implied by 'for the current entry' and by 'The first plan starts the work,' which hints that the initial submission is the entry point. However, no alternative is named and there is no statement about when revision is appropriate versus when a step should instead be marked complete via complete_step.
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.
v2.0.0add_entriescomplete_stepcurrent_stepend_sessionescalateget_matrixget_process_stepget_statusreport_verificationstart_sessionsubmit_planScored across 11 tools
The tools map to mostly distinct workflow phases: matrix discovery, session start, planning, step execution, verification, status, escalation, and ending. Mild overlap exists between current_step and get_process_step (both return procedure-step content) and between complete_step and report_verification (both advance work), but the descriptions clarify when each should be used.
Most names follow a clear snake_case verb_noun pattern such as submit_plan, get_matrix, start_session, complete_step, and end_session. Deviations like current_step (noun phrase) and escalate (bare verb) are minor and still readable, so the set is mostly consistent.
Eleven tools is well-scoped for a session/workflow management server. Each tool appears to earn its place across the session lifecycle, from matrix selection and session start through planning, step execution, verification, escalation, status, and end.
The surface covers the core lifecycle: get matrix, start session, submit plan, advance steps, verify, inspect status, escalate, add entries, fetch procedure steps, and end session. Minor gaps remain around editing or removing entries and richer session listing, but agents can likely work around them.
Task manager for AI agents. Orchestrate agents to achieve large goals in unified control plane.
Task management for teams building with AI agents. Agents claim tasks and report progress.
Shared task layer for AI agents: tasks, handoffs and decisions that persist across tools.
Agent-native task management: your AI agent is the interface. Delegate to anyone by email.
