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., "@StackGuide MCP Server review the codebase for quality issues"
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.
Dynamic context + active engineering workflow for AI coding assistants in Cursor, VS Code, and other MCP clients.
@stackguide/mcp-server helps teams standardize implementation quality with:
project-aware rule/context loading
code review and health scoring
auto-detected setup and stack scaffolding
active agent workflow that executes real work (intake, plan, verify, release)
adaptive TDD preferences per project (model + token profile)
Jira ticket creation from strict MAIN DESCRIPTION templates
tracker + VCS + test orchestration for delivery flow
This server is built for real team usage, not just prompt templates.
Related MCP server: code-health-mcp
Added active agent tool (execution-first workflow).
init now generates .stackguide/config.json automatically.
Added tracker service support for GitHub, GitLab, and Jira.
Added VCS service for branch checks, commit parsing, CI status, and PR/MR creation.
Added test runner service for structured test/lint/build execution.
Updated TDD prompts to use active tool calls instead of large passive markdown payloads.
Hardened local persistence:
.stackguide artifacts removed from version control
repository guard blocks accidental tracking of local artifacts
cache and health history include integrity validation and safer writes
File (workspace): .cursor/mcp.json
File (global): ~/.cursor/mcp.json
{
"mcpServers": {
"stackguide": {
"command": "npx",
"args": ["-y", "@stackguide/mcp-server@latest"]
}
}
}Open Settings | Tools | AI Assistant | Model Context Protocol (MCP).
Click Add and paste JSON config.
Recommended: set it as Project-level unless you want global scope.
{
"mcpServers": {
"stackguide": {
"command": "npx",
"args": ["-y", "@stackguide/mcp-server@latest"]
}
}
}Requirement: GitHub Copilot Chat with MCP enabled.
File (workspace): .vscode/mcp.json
VS Code MCP schema uses servers as root key.
{
"servers": {
"stackguide": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@stackguide/mcp-server@latest"]
}
}
}Enable GitHub Copilot Agent mode.
Supported config locations include:
%USERPROFILE%\\.mcp.json (global)
<solution>\\.mcp.json (repo-scoped)
<solution>\\.vs\\mcp.json (solution/user-scoped)
Visual Studio MCP schema uses servers as root key.
{
"servers": {
"stackguide": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@stackguide/mcp-server@latest"]
}
}
}Restart the IDE after adding the MCP configuration.
Open AI chat in agent/tool mode.
Call setup to detect project context.
Call init action:"full" to scaffold .stackguide/ and defaults.
Use agent actions (intake, create_ticket, plan, verify, release) for delivery flow.
Configure your project:
setup type:"react-typescript" enableAdaptiveTdd:true model:"gpt-5" integrations:["jira","github"] tokenMode:"compact"
init action:"full" model:"gpt-5" tokenMode:"compact" integrations:["jira","github"] mcpSyncTargets:["cursor","root"] applyMcpTemplates:trueCheck generated setup:
init action:"status"
agent action:"status"Run active TDD workflow:
agent action:"intake" ticket:"PROJ-123"
agent action:"create_ticket" mainDescription:"<MAIN DESCRIPTION>" projectKey:"PROJ"
agent action:"plan" brief:"<brief-from-intake>"
agent action:"verify"
agent action:"release" version:"v1.2.0"setup: configure StackGuide context for project type
context: show currently loaded context
rules: list/search/get/select rule sets
knowledge: list/search/get knowledge files
review: analyze files/URLs/project code quality
cursor: browse/import community rules
docs: fetch/search/list documentation
config: save/load/export/import configurations
custom_rule: create/update/delete/list project custom rules
help: usage help by topic
generate: boilerplate generation (component/hook/service/test/api/model/util)
health: project health score and recommendations
analyze: project intelligence (structure/config/dependency/generate/apply)
workflow: lazy-load raw workflow assets (agents/skills/hooks/commands)
init: scaffold .stackguide with stack-aware defaults
agent: active workflow executor (status, intake, create_ticket, plan, verify, release)
agent action:"intake"reads ticket from configured tracker
returns normalized brief + gaps
proposes branch name convention
can optionally create a Jira ticket first (createFromDescription:true)
agent action:"create_ticket"creates Jira issues using strict MAIN DESCRIPTION format
uses project defaults from .stackguide/config.json (projectKey, issueType)
derives summary from first line of MAIN DESCRIPTION when omitted
agent action:"plan"inspects conventions + project shape
creates vertical-slice plan
returns exactly 3 target tests in structured format
agent action:"verify"executes configured tests/lint/build per layer
checks branch naming + commit convention + TDD test budget
returns blocker list and final pass/fail report
agent action:"release"checks CI status
parses commits since last tag
suggests semver impact (major / minor / patch)
can create tag and PR/MR (when enabled)
init generates:
.stackguide/config.json (project workflow config)
Runtime/local artifacts:
.stackguide/analysis-cache.json
.stackguide/health-history.json
These are machine-local and must not be committed.
pnpm lint includes:
pnpm run guard:repoThe guard fails if .stackguide artifacts are tracked.
Cache/history persistence includes:
boundary/symlink checks
file size and entry limits
atomic write strategy
checksum validation
optional HMAC signature using:
STACKGUIDE_INTEGRITY_KEY=<long-random-secret>For teams, configure STACKGUIDE_INTEGRITY_KEY in local/dev and CI environments for stronger tamper resistance.
python-django, python-fastapi, python-flask, react-node, react-typescript, vue-node, nextjs, express, nestjs, laravel, rails, golang, rust, custom.
Use pnpm for all commands.
pnpm install
pnpm lint
pnpm test
pnpm build
pnpm devCurrent secure baseline: 4.1.2+
Versions from 3.0.0 up to 4.1.1 are deprecated in npm due to local artifact hygiene issues.
Use the latest 4.x release in all environments.
npm package: @stackguide/mcp-server
MCP Registry server: io.github.isucorp-taimiralain/stackguide-mcp
GPL-3.0
Active agent workflow actions: intake/plan/verify/release plus Jira ticket creation from strict MAIN DESCRIPTION templates.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Project path (default: current directory) | |
| brief | No | Structured or plain brief text for planning | |
| action | No | Active workflow action | |
| labels | No | Optional labels to set when creating Jira tickets | |
| ticket | No | Ticket key for intake/plan actions (e.g. PROJ-123) | |
| summary | No | Optional Jira summary (defaults to first line of MAIN DESCRIPTION) | |
| version | No | Target release version for release action (e.g. v1.2.0) | |
| createTag | No | If true, release action creates annotated git tag when CI is green | |
| issueType | No | Optional Jira issue type override (Task/Story/Bug) | |
| projectKey | No | Optional Jira project key override | |
| prototypeView | No | PROTOTYPES section value: View | |
| originKeyLogic | No | ORIGIN section value: Key Logic | |
| originOldQuery | No | ORIGIN section value: Old Query | |
| prototypeProps | No | PROTOTYPES section value: Props | |
| destinationView | No | DESTINATION section value: View | |
| mainDescription | No | MAIN DESCRIPTION body used to create Jira tickets | |
| originComponent | No | ORIGIN section value: Component | |
| destinationModel | No | DESTINATION section value: Model | |
| destinationRoute | No | DESTINATION section value: Route | |
| createPullRequest | No | If true, release action opens PR/MR when provider is configured | |
| acceptanceCriteria | No | Acceptance criteria list for strict Jira template | |
| dataTransformation | No | DATA TRANSFORMATION section content | |
| createFromDescription | No | When action is intake, create Jira ticket first from MAIN DESCRIPTION template | |
| destinationController | No | DESTINATION section value: Controller | |
| prototypeRelatedFiles | No | PROTOTYPES related files list | |
| prototypeDesignPattern | No | PROTOTYPES section value: Design Pattern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether actions are destructive, require authentication, or have side effects (e.g., creating tickets or tags).
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 a single concise sentence that front-loads the core purpose. It is efficient but could be structured more clearly with bullet points for actions.
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 26 parameters and no output schema, the description is too brief. It omits explanation of the workflow lifecycle, how actions interrelate, and the meaning of 'strict MAIN DESCRIPTION templates', leaving significant gaps for a complex tool.
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 baseline is 3. The description adds minimal extra meaning beyond the schema—it highlights the MAIN DESCRIPTION template but does not explain parameter relationships or usage context.
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 the tool handles agent workflow actions (intake/plan/verify/release) and Jira ticket creation from MAIN DESCRIPTION templates. It distinguishes from sibling tools like setup or rules by focusing on workflow actions, but the verb 'active' is somewhat vague.
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 guidance on when to use this tool vs alternatives. It lists actions but does not explain the conditions for choosing one action over another, nor does it mention prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project Intelligence: Comprehensive analysis of project structure, configuration, and dependencies. Provides smart recommendations, generates optimal configs, and suggests improvements based on framework best practices.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Project path to analyze (default: current directory) | |
| action | No | Type of analysis to perform | |
| format | No | Output format | |
| autoFix | No | Automatically apply safe fixes (default: false) | |
| configType | No | Config type to generate (for action:"generate") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It uses promotional language ('smart recommendations', 'optimal configs') but does not explain side effects like file modifications (via autoFix), revertability, or performance impact. The potential destructive action of autoFix is implied but not explicitly stated.
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 concise at two sentences, but it contains vague marketing terms ('intelligence', 'smart', 'optimal') that reduce precision. The structure is clear, but conciseness could be improved by replacing fluff with concrete examples.
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?
The description does not explain return values, default behavior when no parameters are provided, or how the tool handles multiple actions. With 5 parameters, all optional, and no output schema, the description should provide more context about the expected output and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description adds general context about the tool's capabilities but does not provide additional semantic details for specific parameters beyond what the schema offers. Baseline of 3 is appropriate.
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 the tool performs comprehensive analysis of project structure, configuration, and dependencies, and generates recommendations and configs. However, it does not distinguish itself from sibling tools like 'generate' or 'config', which may have overlapping functionality.
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 guidance is provided on when to use this tool versus alternatives (e.g., 'config' for config generation, 'review' for code review). There is no mention of prerequisites, typical scenarios, or fallback options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage saved configurations: save, load, list, delete, export, or import.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Configuration ID (for load/delete/export) | |
| json | No | JSON string (for import) | |
| name | No | Configuration name (for save) | |
| action | No | Action to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only says 'manage' and lists actions but does not disclose behavioral traits such as whether actions like 'delete' are destructive, what permissions are needed, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then lists actions concisely. It is appropriately short but could be structured to separate actions from their parameter requirements.
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 output schema and annotations, the description is too minimal. It does not explain what actions require which parameters, what the return format is, or whether actions are reversible. For a tool with 4 parameters and 6 actions, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds no extra meaning beyond the schema: it lists actions but does not clarify parameter-usage rules (e.g., 'name' needed for save, 'id' for load). However, the schema itself describes each parameter adequately.
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 the tool manages saved configurations and lists the supported actions (save, load, list, delete, export, import). It specifies the verb 'manage' and the resource 'configurations', but does not distinguish from sibling tools like 'setup' or '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 description provides no guidance on when to use this tool versus alternatives. It lists actions but does not explain when each is appropriate or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current context with all loaded rules and knowledge. Use this to see what StackGuide has configured.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | Include full rule/knowledge content (default: false, shows summary) |
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 states it retrieves context and mentions the 'full' parameter, but fails to indicate side effects (likely none), read-only nature, or performance implications.
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 well-structured sentences: purpose first, then usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool without output schema, the description adequately conveys what it returns and how to control detail. Could be improved by stating it is read-only and safe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description's mention of 'include full rule/knowledge content (default: false, shows summary)' essentially mirrors the schema description, adding minimal value.
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 'Get current context with all loaded rules and knowledge' – a specific verb and resource. It distinguishes from siblings like 'rules' and 'knowledge' by implying a holistic view.
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 says 'Use this to see what StackGuide has configured', providing a clear usage context. However, it does not mention when not to use or suggest alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse, search, and import rules from cursor.directory community.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Rule slug for import | |
| query | No | Category to browse or search term | |
| action | No | Action to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It does not mention whether the tool is read-only, requires authentication, or has side effects like modifying local configuration. The import action implies some modification, but this is not clarified.
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 a single sentence with no filler, efficient in length. However, it could be improved by listing all possible actions (including popular and categories) to avoid reliance on schema reading.
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?
The description lacks details about return values or results, which is important given no output schema. It does not explain what happens upon import (e.g., local file creation) or how browse/search results are formatted, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema provides descriptions for all three parameters. The tool description adds no additional meaning or context beyond what the schema already conveys, so baseline 3 is appropriate.
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 specifies the tool's action (browse, search, import) and resource (rules from cursor.directory). It distinguishes from sibling tools like rules or knowledge by referencing the community site. However, it omits the 'popular' and 'categories' actions enumerated in the schema, slightly reducing clarity.
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 guidance on when to use this tool versus alternatives such as rules, knowledge, or docs. No explicit context about prerequisites or exclusions, leaving the agent to infer appropriate usage from the actions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, update, delete, or list custom rules for your project.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Rule ID (for update/delete) | |
| json | No | JSON string (for import) | |
| name | No | Rule name | |
| action | No | Action to perform | |
| content | No | Rule content in markdown | |
| category | No | Rule category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description enumerates supported actions (create, update, delete, list, export, import), indicating behavior. However, it does not disclose side effects, permission requirements, or limitations like whether operations are reversible or batch constraints. With no annotations, the description carries the full burden but only partially satisfies it.
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 extremely concise: one sentence listing all core actions without any fluff. Every word contributes to the purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, multiple actions, and no output schema, the description is too brief. It does not explain return values, how to construct the 'json' parameter for import, or how actions like 'list' behave. The agent lacks sufficient information to use the tool confidently.
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?
Input schema has 100% description coverage, so the baseline is 3. The description adds no extra meaning beyond what parameters already provide, such as parameter interdependencies or usage examples.
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?
Description clearly states the tool's primary actions: create, update, delete, or list custom rules. However, it does not differentiate from sibling tools like 'rules' which might manage similar resources, missing specificity about what makes these 'custom' rules.
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 guidance on when to use this tool versus alternatives such as 'rules', 'setup', or 'knowledge'. The description lacks context about prerequisites, preferred usage patterns, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and manage web documentation. Fetch URLs, search cached docs, or list available.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to fetch or document ID | |
| urls | No | Multiple URLs to fetch | |
| query | No | Search query | |
| action | No | Action to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It only mentions fetching, searching, and listing, but hides that 'remove' may be destructive. No side effects, auth needs, or output format mentioned.
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?
Single sentence is brief but lacks detail. It is front-loaded with the main purpose, but could be more concise by listing all actions explicitly.
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 tool with 4 parameters and 6 actions, the description is too sparse. It does not explain how actions relate to parameters, which are required, or expected output.
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 covers all parameters with descriptions. The tool description adds minimal value beyond summarizing high-level functions. Baseline of 3 is appropriate.
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 identifies the tool's domain ('web documentation') and core actions ('Fetch, search, list'), but omits other actions (get, remove, suggest) and does not distinguish from sibling tools.
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 guidance on when to use this tool versus alternatives like 'knowledge' or 'help'. No criteria for choosing among the six actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate boilerplate code from templates. Create components, hooks, services, tests, API routes, models, and utilities with best practices built in.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the generated code (e.g., UserCard, useAuth, ApiService) | |
| type | Yes | Type of code to generate | |
| options | No | Generation options |
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 fails to disclose important behavioral traits such as whether files are created, permissions needed, or side effects. The claim 'with best practices built in' is vague.
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 concise with two sentences. The first sentence clearly states the primary action, and the second enumerates supported types. No unnecessary words.
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 tool has 3 parameters with full schema coverage and no output schema, the description covers the general purpose but omits details about output format, side effects, or behavior. It is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters well. The description adds value by listing code types that map to the 'type' enum, but does not provide substantial additional meaning beyond that.
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 the verb 'generate' and the resource 'boilerplate code from templates', with a specific list of code types. It distinguishes the tool from siblings like 'setup' or 'context' by focusing on code generation.
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 guidance on when to use this tool versus alternatives. The description lacks explicit context about when it is appropriate or not, and does not mention any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive health score for your project. Analyzes configuration, code quality, structure, documentation, and testing readiness. Returns a grade (A-F) with detailed recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| detailed | No | Include detailed breakdown by category (default: true) | |
| projectPath | No | Project path to analyze (default: current project) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It mentions analysis scope and output (grade A-F, recommendations) but does not state if the tool is read-only, whether it requires specific permissions, or any side effects. This is adequate but lacks depth.
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 three concise sentences with no wasted words. It efficiently conveys the purpose, scope, and output format.
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 output schema, the description adequately hints at the return value (grade and recommendations). However, it could be more precise about the response structure. With two optional parameters and no required ones, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional context about the parameters beyond what the schema provides. It could mention that 'detailed' controls the level of granularity, but it doesn't.
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 the tool provides a comprehensive health score for a project, analyzing specific areas (configuration, code quality, etc.) and returning a grade with recommendations. This distinguishes it from sibling tools like 'analyze' or 'review'.
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 usage for project health assessment but does not explicitly state when to use this tool versus alternatives like 'analyze' or 'review'. No exclusion criteria or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get help about StackGuide tools and how to use them.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Help topic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does not disclose what happens when no topic is provided, the output format, or any side effects. The behavior is underspecified.
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 a single sentence with no wasted words. It is front-loaded with the core purpose. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple help tool with one optional parameter and no output schema, the description covers the basic purpose but lacks details on default behavior (e.g., when no topic is specified) and output format. Adequate but not comprehensive.
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% (one parameter with enum and description). The description adds no extra meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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 the tool provides help about StackGuide tools, specifying the verb 'Get help' and the resource 'about StackGuide tools and how to use them.' It is not a tautology and distinguishes from sibling tools by its help-focused role.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it differs from other help-related tools like 'docs' or 'rules.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a project with the StackGuide TDD workflow. Auto-detects your stack and scaffolds a .stackguide/ directory with only the relevant agents, skills, hooks and scripts (including the optional OJ health gate).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Project path (default: current directory) | |
| type | No | Force a project type instead of auto-detecting | |
| model | No | Preferred model identifier saved for adaptive TDD | |
| action | No | Action to perform | |
| tokenMode | No | Token profile for adaptive TDD | |
| integrations | No | External MCP integrations to scaffold in local manifests | |
| jiraIssueType | No | Default Jira issue type (Task by default) | |
| jiraProjectKey | No | Default Jira project key for ticket creation | |
| mcpSyncTargets | No | Target manifest files for MCP synchronization | |
| applyMcpTemplates | No | If true, writes MCP integration templates into selected manifests |
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 discloses the main side effect—scaffolding a .stackguide/ directory with relevant content—and mentions auto-detection. However, it does not detail whether existing files are overwritten, prerequisites (e.g., must be run in project root), or what the 'optional OJ health gate' entails. It gives a moderate level of transparency 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?
The description is a single, focused sentence that front-loads the core purpose. It is concise with no wasted words, providing the key information about stack auto-detection and scaffolding without unnecessary detail.
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 tool has 10 optional parameters and no output schema, the description gives a good high-level overview but omits important context about the 'action' parameter (e.g., detect vs. full vs. status) and what the 'OJ health gate' is. It also does not differentiate this tool from siblings like 'setup', which limits completeness for agent decision-making.
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 each parameter is already documented. The description adds value by mentioning stack auto-detection, which relates to the 'type' parameter, but it does not explain the interplay of params like 'action' (detect/full/status) or 'integrations'. Since the schema covers this well, the description does not need to repeat, but it also does not add meaningful context 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?
The description clearly states the tool's purpose: to initialize a project with the StackGuide TDD workflow. It specifies the action (initialize), the resource (project), and the scope (scaffolds .stackguide/ directory with relevant agents, skills, hooks, scripts). It distinguishes itself from siblings by focusing on stack auto-detection and scaffolding a specific directory.
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 usage for project initialization but does not explicitly state when to use this tool versus alternatives like 'setup' or 'config'. It mentions auto-detects your stack, which hints at usage for new projects, but there are no explicit exclusions or alternatives. The guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage knowledge base: list, search, or get architecture patterns and solutions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term or knowledge ID | |
| action | No | Action to perform | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It implies read-only behavior through the listed actions (list, search, get), but does not disclose potential side effects, authentication needs, or response format. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It front-loads the action verb and resource. However, it omits important details for completeness, so it cannot score the highest.
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 tool has three parameters, no output schema, and no annotations, the description is insufficient. It lacks usage guidelines, behavioral details, and return value expectations. It serves only as a brief purpose statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing descriptions for all three parameters. The description adds the context of 'architecture patterns and solutions' which is not in the schema, but this is marginal beyond the enum values. Baseline 3 is appropriate.
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 the tool manages a knowledge base and specifies the actions (list, search, get) and the resource type (architecture patterns and solutions). It effectively distinguishes from sibling tools which are general-purpose.
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 provides no guidance on when to use this tool versus alternatives like 'docs' or 'review'. It does not mention exclusions or prerequisites, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze code for issues using pattern matching. Detects security vulnerabilities, performance problems, coding standard violations, and architecture issues. Returns a score (0-100) and detailed report with suggestions. Works on files, URLs, or entire projects.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to fetch and review | |
| file | No | File path to review | |
| focus | No | Focus area for review | |
| project | No | Review entire project structure |
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 states it returns a score and report but does not clarify side effects (e.g., whether it modifies files), authentication needs, rate limits, or network access requirements for URLs.
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 concise with four short sentences, front-loading the purpose. No wasted words, but it could be slightly more structured (e.g., bullet points for return value or scope).
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 4 optional parameters and no output schema, the description misses key details: what happens when multiple input types are provided (url, file, project), how the report is structured, and any limitations on project size or URL fetching.
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 each parameter already has a description. The tool description adds context about working on files, URLs, or projects, which aligns with parameters. However, it does not provide additional semantic detail 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?
The description clearly states the tool analyzes code for issues using pattern matching, listing specific categories (security, performance, etc.). It identifies the action (analyze) and resource (code). However, it does not differentiate from sibling 'analyze' tool, which may have overlapping purpose.
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 mentions it works on files, URLs, or projects but provides no guidance on when to use this tool versus alternatives (e.g., 'analyze'), nor does it specify 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.
Manage rules: list, search, get, or select rules for your project.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Rule IDs to select (for select action) | |
| query | No | Search term or rule ID (for search/get actions) | |
| action | No | Action to perform | |
| category | No | Filter by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only lists actions without disclosing effects like state changes (e.g., does 'select' modify something?), authentication needs, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no fluff, but under-specified given four distinct actions and multiple parameters. Could benefit from more detail on action behavior.
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 and no description of return values for each action. Lacks context on default action or required parameter dependencies, making agent reasoning harder.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with brief parameter descriptions. Description adds no extra meaning beyond the schema, so 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?
Description clearly states the tool manages rules and lists four specific actions (list, search, get, select). However, it does not distinguish from sibling tools like custom_rule, and 'manage' is somewhat vague.
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 guidance on when to use this tool versus alternatives (e.g., custom_rule for creating rules). No when-not-to-use indications provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure StackGuide for your project. Auto-detects project type or lets you specify one manually.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Project path (default: current directory) | |
| type | No | Project type to use (auto-detected if not specified) | |
| model | No | Preferred model identifier for TDD runs (saved in .stackguide/config.json) | |
| tokenMode | No | Token profile for prompts and workflow responses | |
| integrations | No | External MCP integrations to scaffold as templates | |
| jiraIssueType | No | Default Jira issue type (Task, Story, Bug...) | |
| jiraProjectKey | No | Default Jira project key used when creating tickets from descriptions | |
| mcpSyncTargets | No | Where MCP template servers should be synchronized | |
| enableAdaptiveTdd | No | Enable the adaptive TDD setup wizard that asks for model and integration preferences |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose behavioral traits such as whether it overwrites existing configuration, requires specific permissions, or is idempotent. Only mentions auto-detection vs manual specification.
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 wasted words, front-loaded with the core action. Purpose is stated immediately.
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 9 parameters, no output schema, and no annotations, the description is too brief. It fails to explain configuration effects, return values, or side effects. Incomplete for a tool of this complexity.
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 baseline is 3. The description adds minimal extra meaning beyond the schema (only relates to 'type' parameter). No added value for other parameters.
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 the tool configures StackGuide for a project, with auto-detection or manual type specification. This is specific and distinguishes it from sibling tools like 'init' or 'config'.
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 use for initial setup but provides no explicit guidance on when to use this tool vs alternatives like 'init' or 'config'. No when-not or exclusion criteria stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDD agentic workflow with lazy loading. Load agents, skills, hooks, commands, scripts and the OJ policy on demand to save tokens. Five roles: Intake → Planner → Implementer → Verifier → Releaser.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the item to load (e.g. "tdd-planner", "tdd-core", "verify", "oj-verify") | |
| action | No | Action to perform | |
| category | No | Filter list by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only mentions lazy loading and the workflow roles. It does not state whether loading is read-only, whether it mutates state, what auth or permissions are needed, or what the tool returns. This is a significant gap for a workflow management 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?
The description is three short sentences, each providing distinct information: the tool's identity, its loading action, and the workflow roles. It is front-loaded and avoids redundancy, though the first sentence is somewhat broad and the roles sentence is not essential for invoking the tool.
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?
The description provides enough context to understand the tool's purpose and the types of items it loads, but with no output schema and no annotations, it leaves gaps about how to use action/name/category together and what happens upon loading. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema, listing item types (agents, skills, hooks, commands, scripts) that correspond to the action enum, but it does not explain how the parameters interact or that all are optional.
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 identifies the tool as a lazy-loading workflow manager for TDD components, specifying the verb 'Load' and the resources (agents, skills, hooks, commands, scripts, OJ policy). It also introduces a distinct five-role pipeline, which helps differentiate it from sibling tools like 'agent' or 'docs', though it does not explicitly name alternatives.
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 usage when needing to load workflow components on demand to save tokens, but it does not explicitly state when to use this tool versus others or provide any exclusions. The 'on demand' phrasing offers some context, but guidance remains implicit rather than clearly instructed.
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. Dates show when Glama detected each change.
v4.2.0workflow3 fields changedInput schema / properties / action / enumPrevious value: -[
- "list",
- "agent",
- "skill",
- "command",
- "hook"
-]New value: +[
+ "list",
+ "agent",
+ "skill",
+ "command",
+ "hook",
+ "script",
+ "policy"
+]Input schema / properties / category / enumPrevious value: -[
- "agents",
- "skills",
- "hooks",
- "commands"
-]New value: +[
+ "agents",
+ "skills",
+ "hooks",
+ "commands",
+ "scripts"
+]Input schema / properties / name / descriptionPrevious value: -"Name of the item to load (e.g. \"tdd-planner\", \"tdd-core\", \"verify\")"New value: +"Name of the item to load (e.g. \"tdd-planner\", \"tdd-core\", \"verify\", \"oj-verify\")"v4.1.6agentanalyzeconfigcontextcursorcustom_ruledocsgeneratehealthhelpinitknowledgereviewrulessetupworkflowSeveral tools have overlapping purposes: knowledge, rules, custom_rule, and cursor all involve managing rules or knowledge, while review, analyze, and health all analyze project quality. Workflow, init, and agent also cover overlapping workflow functionality, making it difficult to choose the correct tool.
All tool names are lowercase with underscores for multi-word names, but there is no consistent verb-noun pattern. Names mix verbs (generate, review, analyze) and nouns (health, context, workflow), and some are ambiguous (setup vs init, agent vs workflow).
With 16 tools, the count is slightly above the typical 3-15 range but reasonable given the broad scope of the server (project setup, code analysis, workflow management). Each tool appears to serve a distinct purpose in the overall system.
The tool surface covers major workflows like code review, project analysis, rule management, and TDD workflow initialization. However, knowledge management lacks create/update/delete operations, and there is no obvious way to manage docs entries beyond fetching/searching, leaving some gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Governance copilot for AI-assisted coding. 72 packs, 532 rules, proof bundles.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Your team's shipping standards, org map and delivery metrics, inside your coding agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/isucorp-taimiralain/StackGuide-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
