A
licenseNot graded
qualityD
maintenanceEnforces engineering governance for AI-driven software projects, ensuring state over prompt, freeze over generate, and audit over output through the 5S workflow.
1
MIT
Structured Workflow MCP
by kingdomseed
This server enforces disciplined, phase-based development workflows for AI assistants, requiring structured documentation and validation at each stage before proceeding.
Workflow Types:
Refactoring workflows - Improve existing code through mandatory audit, analysis, planning, implementation, testing, and iteration phases
Feature development workflows - Build new functionality with integrated testing and documentation requirements
Test coverage workflows - Add or improve test coverage with systematic analysis
TDD workflows - Implement features using Red-Green-Refactor cycles with test-first principles
Custom workflows - Design workflows with full control over phases, iteration limits, and output preferences
Core Capabilities:
Enforce sequential execution - Mandate specific phases in order, preventing skipping through session state management and validation
Require verified outputs - Force production of structured artifacts (JSON, markdown) at each phase completion using the
phase_outputtoolValidate actions and progress - Check safety rules (e.g., files must be read before modification via
validate_action) and verify phase completion meets requirementsProvide phase-specific guidance - Deliver focused instructions for each phase (SETUP, AUDIT_INVENTORY, COMPARE_ANALYZE, QUESTION_DETERMINE, WRITE_OR_REFACTOR, TEST, LINT, ITERATE, PRESENT)
Track workflow status - Monitor current progress and session state throughout execution
Handle escalation - Trigger user input when iteration limits are reached, checkpoints are hit, or validation failures occur
Auto-suggest file organization - Generate numbered, timestamped file naming for workflow documentation (e.g.,
01-audit-inventory-2025-01-04.md)
Configuration Options:
Set iteration limits for LINT, TEST, and ITERATE phases
Define user checkpoints for major changes or after failures
Customize output formats (markdown/JSON), directories, real-time updates, diagrams, and code snippets
Scope workflows to specific files, directories, or entire projects
Includes a 'Buy Me a Coffee' link in the README for supporting the developer through donations.
Built with TypeScript, providing type-safe development for the MCP server implementation.
Click on "Install 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., "@Structured Workflow MCPrefactor the authentication module to improve security"
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.
Structured Workflow
IMPORTANT
Work in progress. The 20 workflow skills are available for review and experimentation. Project initialization, templates, companion subagents, hooks, and packaged installation are still being designed.
Structured Workflow started as an MCP server in the Sonnet 3.5/3.7 era, when I was trying to answer a question: “How do I get my agents to follow a more structured approach, like a human would, when facing new problems and unknown territory?” This update evolves that idea by bringing in the MYP Design Cycle from my years as a teacher as the core process for building anything with agents.
Structured Workflow is a collaborative skillset for agents and humans. It gives coding agents an evidence-producing design cycle as a workflow structure, guiding them through the reasoned process that a product developer, designer, or engineer would use when approaching and solving a problem. It can be lightweight or support detailed analysis and research. It provides a useful default direction while allowing the work to follow new questions, ideas, prototypes, implementation discoveries, and evaluation evidence wherever they lead.
The repository currently contains 20 skills: one parent and four criterion skills for each of four phases. It also defines the durable project files that preserve shared understanding and workflow position across sessions.
The design cycle
The default direction is to work through phases A–D, one criterion at a time. Work can move to any criterion or phase that best answers the current question. Research, ideas, exploratory visuals, and evaluation can move naturally between criteria as the current question changes.
A — Inquire and Analyze
A1 — Explain and justify the need
A2 — Identify and prioritize research
A3 — Analyze prior art
A4 — Develop the Design Brief
The phase produces an approved Design Brief supported by inquiry evidence.
B — Develop Ideas
B1 — Develop design specifications
B2 — Develop feasible ideas
B3 — Present and justify the chosen design
B4 — Develop planning drawings and diagrams
The phase produces an approved Spec that defines the chosen solution.
C — Create Solution
C1 — Construct a logical plan
C2 — Demonstrate technical skills
C3 — Follow the plan to create the solution
C4 — Justify changes to the design
The phase produces approved tickets, a working solution, verification evidence, and justified changes.
D — Evaluate
D1 — Design testing methods
D2 — Evaluate the solution against the design specification
D3 — Explain how the solution could be improved
D4 — Explain the solution's impact
The phase produces an evidence-backed verdict, improvements, and an impact explanation.
The default direction inside A and B follows criterion order. Criterion C starts with C1, demonstrates C2 while carrying out C3, and uses C4 when creation requires a design change. A complete final evaluation follows D1 through D4.
Evaluation is also available throughout the cycle. A Design Brief, Spec, plan, ticket set, prototype, implementation, or claim can be evaluated whenever the work needs an evidence-based judgment.
Related MCP server: Universal Spec Architect
How artifacts develop
Each phase maintains one authoritative project document:
The inquiry document preserves A1–A4 evidence and produces the Design Brief.
The developing-ideas document preserves B1–B4 evidence and completes the Spec.
The creating-solution document preserves the logical plan, technical skills evidence, creation record, and justified changes. Approved implementation tickets live in the project's issue tracker.
The evaluation document accumulates reviews and final evaluation evidence.
The documents preserve the reasoning behind each handoff. A later phase can load the approved artifact first and retrieve deeper evidence from the owning phase document when needed.
Durable project context
Structured Workflow uses a small set of project files to survive context loss:
AGENTS.mdcontains the short, always-loaded workflow rules.workflow-tracker.mdrecords the current phase, exact criterion, current question, active artifact, target result, and likely next move.GLOSSARY.mdpreserves the shared meaning of important project terms.Phase documents preserve findings, evidence, decisions, and uncertainty.
Project templates define the document locations and reusable expectations, including the project's Definition of Done.
The tracker records position rather than findings. Research and reasoning belong in the phase document that owns them. Implementation work belongs in the issue tracker.
Human-agent collaboration
Prefer retrieval-led reasoning over training-led reasoning. The agent begins with the project, its code or materials, direct human knowledge, and primary sources. Material claims are cited where they are recorded. Supported facts, human judgments, inferences, and unknowns remain distinguishable.
The agent develops questions from the request, project evidence, industry evidence, contradictions, constraints, and missing understanding. It leads retrieval, review, synthesis, and other bounded work. The human directs intent, priorities, values, and consequential choices. The balance can be even or mostly agent-led, depending on the human and the work.
This evidence trail gives the human a concrete basis for inspecting the agent's reasoning, evidence, and uncertainty.
Repository status
The current repository includes:
the always-loaded workflow rules in
AGENTS.md;four parent skills and sixteen criterion skills under
skills/;four human-facing phase guides;
a project-level workflow tracker template.
The following surfaces are still planned:
project initialization and document templates;
companion subagent definitions;
continuity and guardrail hooks;
packaged installation and update commands.
The skills can be inspected and tested now, but the repository does not yet provide a complete installer. Projects using the workflow must currently place the skills and project files through their agent harness's normal configuration mechanism.
Repository structure
AGENTS.md
README.md
skills/
inquiry-analysis/
README.md
start-inquire-and-analyze/
explain-and-justify-the-need/
identify-and-prioritize-research/
analyze-prior-art/
develop-design-brief/
developing-ideas/
README.md
start-develop-ideas/
develop-design-specifications/
develop-feasible-ideas/
present-and-justify-the-chosen-design/
develop-planning-drawings-and-diagrams/
creating-solution/
README.md
start-create-solution/
construct-a-logical-plan/
demonstrate-technical-skills/
follow-the-plan-to-create-the-solution/
justify-changes-to-the-design/
evaluating/
README.md
start-evaluate/
design-testing-methods/
evaluate-against-the-design-specification/
explain-how-the-solution-could-be-improved/
explain-the-solutions-impact/
workflow-management/
workflow-tracker.mdThe phase folders organize the skills; they are not additional workflow phases.
workflow-management/ contains cross-phase project resources.
Sources and acknowledgments
Structured Workflow adapts the four criteria of the IB MYP Design Cycle for human-agent software work.
The criterion structure was checked against the IB MYP Design Subject Brief and the diagrams published by Design and Inquiry.
The workflow and skill design were informed by:
OpenAI's Product Design skill pack
The human-judgment and evidence-trace principles were also informed by Shaw and Nave's research on cognitive surrender.
Available Tools
20 toolsaudit_inventory_guidanceA
Get guidance for the AUDIT_INVENTORY phase - analyze code and catalog changes
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states it provides guidance, but does not mention whether it is read-only, requires authentication, or what 'guidance' entails (e.g., textual steps, examples).
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 a single sentence that efficiently conveys the purpose and scope. It is front-loaded with the phase name and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a no-parameter tool but lacks details about the output or how guidance is presented. With no output schema, more context on the format (e.g., text, list) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter semantics. The baseline is 4 for no parameters, and the description is adequate.
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 description clearly states it provides guidance for the AUDIT_INVENTORY phase, specifying the action 'analyze code and catalog changes'. This distinguishes it from sibling guidance tools focused on other phases (e.g., iterate_guidance, setup_guidance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during the AUDIT_INVENTORY phase but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned despite multiple sibling guidance tools existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_custom_workflowA
Build a custom workflow with full control over phases and configuration. Use specific workflow tools (refactor_workflow, create_feature_workflow, etc.) for optimized presets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Description of the programming task | |
| workflowType | No | Use a predefined workflow type or custom for full control | custom |
| selectedPhases | No | Select which phases to include in your workflow | |
| iterationLimits | No | Set iteration limits before escalation to user input | |
| outputPreferences | No | ||
| userCheckpoints | No |
TDQS
A3.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description only states the tool's purpose and alternatives, but fails to disclose important behavioral traits such as whether it creates a new workflow, modifies an existing one, requires authentication, or has any side effects.
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 two sentences long, front-loaded with the core purpose, and immediately followed by guidance on alternatives. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters including nested objects, and no output schema. The description is too brief to cover the tool's complexity. It does not explain what the tool returns, how iteration limits work, or typical usage patterns, leaving gaps for an AI agent to understand the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes parameters well with coverage of 67%. The description adds minimal extra meaning beyond stating 'full control over phases and configuration', which is already implied by the schema. Baseline of 3 is appropriate.
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 description uses the specific verb 'Build' with 'custom workflow' as the resource, clearly distinguishing the tool's purpose. It explicitly contrasts with sibling tools by noting that optimized presets are available via refactor_workflow, create_feature_workflow, etc.
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 guidance on when to use this tool ('for full control') vs when to use alternatives ('Use specific workflow tools for optimized presets'). This gives a clear decision criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_analyze_guidanceA
Get guidance for the COMPARE/ANALYZE phase - evaluating approaches
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states that the tool 'gets guidance,' which is a minimal read behavior. It does not describe what the guidance consists of, whether it is static or dynamic, or any side effects. The description lacks transparency about the tool's actual behavior beyond its basic function.
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 a single, concise sentence that communicates the tool's purpose without any superfluous words. It is well-structured and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and no annotations. The description states its purpose but does not elaborate on the form or content of the returned guidance, nor does it provide context about how the guidance relates to the broader workflow. It is minimally complete for a simple guidance tool but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so schema coverage is 100% by default. The description does not add any parameter information, but none is needed since there are no parameters. Baseline score of 3 is appropriate.
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 description clearly states the tool's purpose: to get guidance for the COMPARE/ANALYZE phase, specifically for evaluating approaches. The verb 'get' and resource 'guidance' are specific, and the phase name distinguishes it from sibling guidance tools for other phases (e.g., audit, iterate, test).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used during the COMPARE/ANALYZE phase by naming that phase, but it does not explicitly state when to use or when not to use it, nor does it mention alternatives among the sibling guidance tools. Usage guidance is implicit but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_feature_workflowC
Start a structured workflow for adding new functionality with integrated testing
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Description of the feature to create | |
| context | No | Additional context (optional) |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions 'structured workflow' and 'integrated testing' but does not disclose what actions are taken, such as file creation, test execution, or user prompts. The agent has little insight into side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with the key action. However, it could benefit from a second sentence to clarify scope or output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a workflow tool with nested parameters and no output schema, the description is too brief. It lacks details on workflow steps, return value, or integration with sibling tools. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds no additional meaning beyond the schema, which already explains 'task' and 'context' with sub-properties. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Start' and resource 'structured workflow for adding new functionality with integrated testing'. It distinguishes from siblings like tdd_workflow and test_workflow by emphasizing integrated testing, but could be more specific about the unique workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites or conditions provided. The user must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_workflow_toolsA
List the workflow guidance tools provided by this MCP server
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states the action (list), but does not disclose whether the operation is read-only, requires authentication, or what happens if no tools are available. For a benign listing tool, this is minimally adequate.
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 a single concise sentence that front-loads the key information. Every word is necessary, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is sufficiently complete. It explains what the tool does without needing extra details about return format, as a list of tool names is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), so the description adds no param-specific details. However, the baseline for zero parameters is 4, and the description adds the context that tools are from 'this MCP server', which is useful beyond the schema.
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 description clearly states the verb 'List' and the resource 'workflow guidance tools provided by this MCP server'. It distinguishes the tool from siblings, which are individual guidance or workflow tools, making it clear this is a discovery endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need to see available tools), but lacks explicit when-not or alternative tools. However, for a simple listing tool, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
iterate_guidanceA
Get guidance for the ITERATE phase - fixing issues
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool is read-only, requires authentication, or has side effects. The description adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It could be slightly more informative, but it is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, so the description carries full weight. It explains the phase and purpose adequately but lacks details on the type of guidance provided, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters; schema coverage is 100%. With zero parameters, the baseline is 4. The description adds no parameter details, but none are needed.
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 description clearly states the tool provides guidance for the ITERATE phase with the specific focus of 'fixing issues'. This distinguishes it from sibling guidance tools for other phases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use during the ITERATE phase when fixing issues, but provides no explicit guidance on when to use versus other guidance tools or any exclusions. Context signals show no additional hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lint_guidanceA
Get guidance for the LINT phase - verifying code quality
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the purpose and does not disclose any side effects, authorization needs, or expected behavior (e.g., read-only, caching). For a query-like tool, this is minimal.
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 a single sentence that is front-loaded and concise. Every word earns its place, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple purpose, the description is largely complete. However, it could be improved by mentioning that it provides guidance specific to code quality verification during linting, which is slightly redundant but sufficient. Sibling differentiation is implicit via the phase name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description adds no additional meaning beyond the schema, but the baseline for zero parameters is 4 according to guidelines.
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 description clearly states the tool's purpose: to get guidance for the LINT phase, specifically verifying code quality. It uses a specific verb and resource, and it distinguishes itself from sibling tools like test_guidance or refactor_guidance by naming the phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like iterate_guidance or setup_guidance. It does not mention any prerequisites, exclusions, or context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
phase_outputA
Record the output/results when completing a workflow phase - REQUIRES ACTUAL OUTPUT ARTIFACTS with numbered file naming
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| phase | Yes | The phase you are completing | |
| output | Yes | The results/findings from this phase | |
| outputArtifacts | Yes | MANDATORY: List of actual output artifacts you created for this phase (use numbered file names) |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a key requirement: 'REQUIRES ACTUAL OUTPUT ARTIFACTS with numbered file naming'. This informs the agent of a critical behavioral constraint. It does not cover other aspects like authentication or side effects, but for a recording tool, the given transparency is adequate.
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 a single, efficient sentence. It conveys the essential purpose and a critical requirement without extraneous text. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (nested objects, three required params, no output schema) and the presence of complete schema descriptions, the description covers the core functionality and a key constraint. It is slightly incomplete in explaining the return value, but that is not critical for this tool's use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a minor note about 'numbered file naming' which is also present in the schema. Beyond that, it does not provide additional semantic value, meeting the baseline.
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 description clearly states the tool's purpose: 'Record the output/results when completing a workflow phase'. The verb 'Record' and resource 'output/results' are specific. It distinguishes from sibling tools by focusing on output recording rather than guidance or validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when completing a workflow phase and emphasizes mandatory output artifacts. However, it does not explicitly state when not to use this tool or mention alternatives like validate_phase_completion. The guidance is present but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
present_guidanceA
Get guidance for the PRESENT phase - summarizing work
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'get guidance' without explaining what guidance entails, side effects, or permissions. The description adds little beyond the tool name.
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?
Single sentence with necessary information, front-loading 'PRESENT phase'. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given multiple sibling guidance tools and no output schema, the description is minimal. It does not explain what the guidance response contains or how to use it, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0), and schema coverage is 100%. Baseline for 0 parameters is 4. The description does not need to add parameter info, but it adds some context about the phase.
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?
Description clearly states 'Get guidance for the PRESENT phase - summarizing work', specifying the verb (Get guidance) and resource (PRESENT phase). It distinguishes from sibling tools like iterate_guidance or compare_analyze_guidance which target other phases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for the PRESENT phase but does not explicitly state when to use this tool over alternatives like compare_analyze_guidance or setup_guidance. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
question_determine_guidanceC
Get guidance for the QUESTION_DETERMINE phase - clarify and finalize plan
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
C2.9/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description gives no behavioral context. It does not state whether the tool is read-only, if it modifies state, or any other side effects. The agent is left guessing about the tool's impact.
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 a single concise sentence that front-loads the key information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief given the lack of output schema and annotations. It does not explain what the guidance will contain, how to interpret it, or any additional context needed for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is fully covered. The description adds no parameter details, but that is acceptable since no parameters exist. The purpose is made clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing guidance for a specific phase (QUESTION_DETERMINE) and mentions the goal of clarifying and finalizing the plan. It distinguishes itself from sibling guidance tools by naming a unique phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies use during the QUESTION_DETERMINE phase but does not specify preconditions, when not to use, or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refactor_guidanceB
Get guidance for the WRITE/REFACTOR phase - implementing changes
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states 'Get guidance,' implying a read-only, non-destructive operation, but does not disclose any behavioral traits such as side effects, auth needs, or rate limits. The description is insufficient for a full behavioral understanding.
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 a single sentence that front-loads the purpose. Every word is necessary, and it is appropriate for a tool with no parameters. No wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, few other tools, and zero parameters, the description is minimally adequate. It tells the agent the phase and action, but lacks details on what the guidance contains or how it is structured. It is complete enough for a simple guidance tool but could be improved with more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4 per instructions. The description adds context that the guidance is for the refactor phase, which provides some meaning beyond the empty schema. However, it doesn't elaborate on any potential inputs, which would be unnecessary given no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides guidance for the WRITE/REFACTOR phase, which is a specific phase. It distinguishes from sibling tools like 'setup_guidance' and 'test_guidance' by naming the phase, but the description does not explicitly contrast with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used during the WRITE/REFACTOR phase but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, leaving ambiguity about when to choose this over other guidance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refactor_workflowB
Start a structured refactoring workflow to improve existing code without changing functionality
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Description of what you want to refactor | |
| context | No | Additional context (optional) |
TDQS
B3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly states the behavioral constraint of no functionality change, but omits other aspects like whether the workflow is synchronous, requires user input, or has side effects.
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?
Single sentence that is concise and front-loaded with the action. All words are necessary and contribute to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema or description of return value. For a workflow-starter, the agent would benefit from knowing what to expect (e.g., a status or workflow ID). Also no mention of how the workflow progresses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. However, the description adds no additional meaning beyond the schema; it does not explain how parameters like 'task' or 'context' are used in the workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a refactoring workflow to improve code without changing functionality. It distinguishes from sibling 'refactor_guidance' by specifying it as a workflow, but could be more precise about what starting a workflow entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'refactor_guidance' or 'create_feature_workflow'. The description does not provide context for appropriate use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
setup_guidanceA
Get guidance for the SETUP phase - initialize workflow and establish patterns
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only operation ('get guidance') but does not explicitly disclose behavioral traits like side effects or safety. Adequate but minimal.
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?
Single sentence, front-loaded with purpose. No wasted words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the phase and purpose adequately. Could mention expected output type but not necessary for basic guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema, so parameter semantics are not applicable. Description does not add anything about parameters, but baseline for zero parameters is 4 as no additional value is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the verb 'get guidance' and resource 'SETUP phase'. It distinguishes from sibling guidance tools by naming the phase, though could be more precise about what 'guidance' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that it is for the SETUP phase during initialization, but lacks explicit when-to-use or when-not-to-use guidance and does not reference alternatives despite many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tdd_workflowC
Start a Test-Driven Development workflow with Red-Green-Refactor cycles
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Description of the feature to develop using TDD | |
| context | No | Additional context (optional) |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only mentions the workflow name without disclosing side effects, required permissions, or whether it modifies files or runs commands.
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?
Single sentence, no redundant words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With nested objects, no output schema, and no annotations, the description is too sparse. It doesn't explain return values or how the workflow interacts with the environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates a TDD workflow with Red-Green-Refactor cycles, which distinguishes it from sibling tools like 'test_workflow' or 'refactor_workflow'. However, it could be more specific about what 'starting' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'test_workflow' or 'create_feature_workflow'. The description lacks context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test_guidanceA
Get MANDATORY guidance for the TEST phase - execute tests and validate functionality after refactoring
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as side effects, security requirements, or rate limits.
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?
Single sentence, front-loaded with key information, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately conveys its purpose and context, though return format is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds context about the guidance's purpose, which is meaningful.
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 description clearly states the tool provides mandatory guidance for the TEST phase after refactoring, distinguishing it from sibling tools like test_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use (test phase after refactoring) but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test_workflowC
Start a focused workflow for writing or improving test coverage
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Description of what to test or test coverage to add | |
| context | No | Additional context (optional) |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, required permissions, or whether the workflow is mutable. It only states the action without detail.
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 a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested input schema and lack of output schema, the description is too brief. It doesn't explain what the workflow does, its output, or any side effects, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents parameters adequately. The tool description adds no extra meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a workflow for writing or improving test coverage, with a specific verb and resource. However, it doesn't differentiate from similar sibling tools like tdd_workflow or test_guidance, preventing a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description implies usage for test coverage tasks but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
user_input_required_guidanceA
Handle escalation to user input when iteration limits reached or checkpoints triggered
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| trigger | Yes | What triggered the escalation | |
| context | No | Additional context about the escalation |
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the high-level action ('handle escalation') without detailing what happens post-escalation (e.g., tool behavior, side effects, or expected return). This is insufficient for an agent to understand consequences.
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?
Single sentence, front-loaded with key action and conditions. No redundant or unnecessary words. Efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is adequate but lacks guidance on what happens after escalation or how the agent should proceed. It covers the trigger conditions but is incomplete for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameters well. The description adds no extra meaning beyond listing trigger conditions. Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 description clearly states the verb 'Handle escalation', the resource 'user input', and the conditions 'when iteration limits reached or checkpoints triggered'. This is specific and distinct from sibling tools, which are more about general guidance or workflow actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (when iteration limits or checkpoints are triggered), but does not explicitly mention when not to use it or suggest alternative tools among the siblings. The usage is implied rather than explicitly bounded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_actionC
Check if an action follows critical safety rules
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action you want to take | |
| targetFile | Yes | The file you want to act on |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'check', implying a read operation, but does not specify side effects, permissions, or return value. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence without fluff. It is concise, though it could benefit from more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It does not explain what the tool returns (e.g., boolean, error list) or how to interpret results, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already described. The tool description adds no further semantics beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if an action follows critical safety rules. It uses a specific verb and resource, but lacks detail on what constitutes 'critical safety rules', making it slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings like 'validate_phase_completion'. There is no mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_phase_completionC
Validate that current phase meets all completion requirements before allowing progression
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| phase | Yes | The phase to validate | |
| completedWork | Yes | Description of work completed in this phase | |
| createdFiles | No | List of files created during this phase |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden, but it fails to disclose outcomes of validation (e.g., success/failure, side effects), required permissions, or error handling. The tool's behavior beyond the basic function is opaque.
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?
A single, clear sentence with no extraneous information. Every word serves a purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain return values and completion requirements. It does not, leaving agents uncertain about validation logic and expected outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds no additional meaning for parameters. It does not clarify how 'completedWork' content or 'createdFiles' list affect validation criteria.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates phase completion before progression, using a specific verb and resource. It distinguishes from sibling guidance tools, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, and does not mention prerequisites or exclusions. Siblings include many guidance and workflow tools, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow_statusA
Check current workflow progress and session state
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only says 'check', implying read-only, but does not confirm lack of side effects, authentication needs, or what 'session state' entails.
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 a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It does not explain what kind of progress information is returned, whether it is synchronous, or how it relates to sibling status-checking tools. For a tool with no parameters, it is somewhat complete but lacks helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description does not need to add parameter meaning. The baseline for 0 params is 4, and the description is adequate.
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 description clearly states the action ('check') and the resource ('current workflow progress and session state'). It distinguishes itself from sibling tools like build_custom_workflow and discover_workflow_tools by focusing on status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.7/5.0
Disambiguation5/5
Each tool targets a distinct phase or action, with clear guidance tools for specific workflow stages and separate workflow building tools. There is no overlap in purpose.
Naming Consistency4/5
Most tools follow a 'verb_noun' or 'phase_guidance' pattern with underscores, but 'phase_output' deviates slightly. Overall, the naming is mostly consistent and predictable.
Tool Count5/5
With 20 tools covering guidance for various phases, workflow stereotypes, validation, and status, the count is well-scoped for a workflow-oriented server.
Completeness5/5
The tool set comprehensively covers the full workflow lifecycle from setup through completion, including guidance for common phases, multiple workflow types, and validation checks.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Deterministic AI code review, with an audit record. Governance inside the agent loop.
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
Verifies AI agent work end to end: real artifacts and outcomes checked, not self-reported success.
Architecture compiler for AI code. 11 tools, 92 actions, 872 Lean4 proofs, 100/100 self-cert.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnforces a rigorous spec-driven engineering workflow for AI coding assistants, requiring requirements, design, and task planning before any code is written.
- AlicenseNot gradedqualityCmaintenanceProtocol-enforced learning system combining memory-augmented reasoning with workflow automation to improve AI assistant reliability by ensuring they learn from past experiences before making code changes.12MIT
- AlicenseNot gradedqualityAmaintenanceEnforces structured, evidence-guided software engineering tasks with cognitive actions (investigate, plan, verify, remember) and persistent state for LLM-based coding agents.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kingdomseed/structured-workflow'
If you have feedback or need assistance with the MCP directory API, please join our Discord server