Provides tracker and VCS integration for branch checks, commit parsing, CI status, and PR/MR creation.
Provides tracker and VCS integration for branch checks, commit parsing, CI status, and PR/MR creation.
Allows creating Jira tickets from strict MAIN DESCRIPTION templates and reading tickets for intake.
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 Initialize full project setup with Jira integration"
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: Mimir
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 lacks behavioral details such as side effects, authentication needs, or return behavior. It mentions 'strict MAIN DESCRIPTION templates' but does not explain what happens during each action (e.g., mutations, ticket creation 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, concise sentence that packs the key actions and template requirement without unnecessary words. However, it could be slightly more structured by grouping action categories.
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 complexity (26 parameters, no output schema, no annotations), the description is insufficient. It does not explain how actions work together, the expected workflow sequence, or how parameters like 'mainDescription' and 'createFromDescription' interact.
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 input schema already defines all 26 parameters with descriptions. The tool description adds minimal value by listing the action enum and mentioning templates, but does not clarify parameter relationships or usage patterns 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 is for 'Active agent workflow actions' and lists specific actions (intake/plan/verify/release) plus Jira ticket creation. It provides a clear verb-resource mapping but could be more explicit about the scope versus sibling tools like 'workflow'.
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 given on when to use this tool versus alternatives (e.g., sibling tools like 'workflow' or 'generate'). The description does not mention exclusions, prerequisites, or context-dependent recommendations.
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?
No annotations provided; description carries full burden. It mentions 'generates optimal configs' and 'suggests improvements' but does not disclose that the 'apply' action and 'autoFix' parameter can modify files. The potential for side effects is not transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the first sentence ('Project Intelligence: Comprehensive analysis...') is somewhat redundant. It is reasonably concise but could be tighter without losing meaning.
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 5 parameters, no required, and no output schema, the description should explain output format and behavior for each action. It mentions recommendations and config generation but not the structure of the response, and omits details about the 'action' modes like 'full', 'structure', etc.
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 parameter descriptions. The description adds overall context ('comprehensive analysis') but does not enhance individual parameter semantics beyond what the schema provides.
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 it performs 'comprehensive analysis' and 'generates optimal configs', but does not distinguish from sibling tools like 'generate' which may also create configurations. The verb 'analyze' and resource 'project' are evident, but sibling differentiation is missing.
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 'workflow', 'generate', or 'health'. The description lists capabilities but lacks context for agent decision-making.
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?
With no annotations provided, the description fails to disclose behavioral traits such as persistence, authentication requirements, side effects (e.g., overwrite on save), or return values. The word 'manage' implies modification but no specifics are given. The description carries the full burden but offers minimal behavioral context.
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 listing actions, which is concise and front-loaded. It contains no unnecessary words. However, it could be improved by structuring the actions as a bullet list for readability, but it is still efficient.
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 4 parameters, 6 actions, and no output schema, the description is incomplete. It does not specify expected return values (e.g., list returns IDs, export returns JSON), error conditions, or parameter-action associations. An agent cannot fully understand the tool's behavior from this description alone.
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 descriptions for all parameters, so the baseline is 3. The description adds no additional parameter-level guidance, such as which parameters are required for each action. It does not improve understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage saved configurations' and enumerates specific actions (save, load, list, delete, export, import), which gives a clear purpose. However, it does not differentiate from sibling tools like 'setup' or 'init' that may also manage configuration, and 'manage' is a vague verb. The resource is clear but the uniqueness is not emphasized.
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. The description only lists capabilities without any context about prerequisites, exclusions, or typical use cases. A developer would need to infer from names like 'setup' or 'init' which might overlap.
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 present, and description only says 'Get' without clarifying side effects, permissions, or whether full content retrieval is expensive. Minimal behavioral disclosure.
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 concise sentences front-load the purpose and usage, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains what the tool returns and hints at configuration view. Lacks output format details but sufficient for a simple retrieval 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 covers the only parameter ('full') with clear description; description adds no extra meaning, meeting the baseline for 100% coverage.
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?
Clearly states it retrieves current context with rules and knowledge, distinguishing it from sibling tools like 'rules' or 'knowledge' by being a combined 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?
Provides a simple use case ('see what StackGuide has configured') but does not mention when to avoid or suggest alternatives like specific rule or knowledge queries.
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?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only or destructive. The 'import' action might imply modification, but this is not clarified. The description falls short of informing the agent about 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose, front-loading the key action and resource. It is concise and avoids unnecessary words, earning a high score for conciseness given the tool's relative simplicity.
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 absence of an output schema and annotations, the description should provide more context about return values or behavioral outcomes. It only gives a high-level purpose without specifying what happens after each action (e.g., results of search, confirmation of import). The description is insufficient for an agent to fully understand the tool's 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?
The input schema covers all three parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds no additional meaning beyond the schema—it does not explain how parameters like 'slug' or 'query' relate to the actions, leaving the agent to rely solely on 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: browsing, searching, and importing rules from the cursor.directory community. It specifies both the action (browse, search, import) and the resource (rules from cursor.directory), effectively distinguishing it from sibling tools like 'rules' or 'knowledge' which may have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for interacting with community rules, but it does not explicitly state when to use it versus alternatives (e.g., 'rules' or 'knowledge'). No exclusions or conditions are provided, so while the use case is clear, the guidance is minimal.
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?
With no annotations, the description must disclose behavioral traits. It mentions create, update, delete, and list, but omits export/import actions present in the schema. No info on side effects, auth requirements, or irreversible operations like delete.
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, which is concise but not well-structured for a multi-action tool. It front-loads the purpose but lacks details that earn its place.
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's complexity (6 params, 6 actions, no output schema), the description is too brief. It misses crucial details like required parameters per action, import/export behavior, and result format.
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 no extra meaning beyond the schema; it doesn't explain how parameters group by action (e.g., content and category for create/update, id for update/delete).
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 'Create, update, delete, or list custom rules for your project' clearly states the verb and resource, covering the main actions. It distinguishes the tool as managing custom rules, but doesn't differentiate from sibling tools like '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 like 'rules' or 'knowledge'. The description lacks context about prerequisites, when to choose a specific action, or when to avoid 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 fully disclose behavior. It mentions read actions (fetch, search, list) and implies write actions (remove) but does not clarify idempotency, side effects, authorization needs, or whether mutations are reversible. Destructive behavior like 'remove' is hidden.
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 with front-loaded purpose ('Fetch and manage web documentation') and a compact list of actions. No redundancy, though it could be slightly restructured to separate behavioral warnings without losing conciseness.
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 mixed-use tool with 4 params, no output schema, and no annotations, the description is insufficient. It omits return value descriptions, error handling, destructive action warnings, and does not explain the 'get', 'remove', or 'suggest' actions even though they are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters. The description adds a high-level summary of actions but does not provide additional meaning beyond what the schema already offers (e.g., no format or usage examples). 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 uses specific verbs 'Fetch and manage' and lists actions (fetch, search, list), indicating the tool is for web documentation. It distinguishes from sibling tools like 'help' and 'workflow' which are not documentation-focused, though no explicit differentiation is stated.
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. The description does not explain when to choose 'fetch' over 'search' or 'list', nor does it mention prerequisites or exclusions. The agent gets no decision support.
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 fully convey behavior. It only states creation from templates but omits details like file creation side effects, overwrite behavior, or output location, leaving significant behavioral gaps.
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 concise sentences that front-load the main purpose and immediately list supported types. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a high-level overview but lacks detail on generation behavior, output structure, or how options affect results. Given the nested options parameter and no output schema, more completeness would aid correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by listing examples (e.g., UserCard) and mentioning best practices, but does not significantly deepen understanding 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 it generates boilerplate code from templates and lists specific code types (components, hooks, etc.), matching the 'type' enum. It distinguishes from sibling tools like 'init' or 'workflow' by specifying template-based 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?
The description implies usage when needing boilerplate code but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned despite siblings being unrelated.
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?
No annotations are provided, so the description carries the full burden. It states 'analyzes' and 'returns' which implies read-only behavior, but does not explicitly state that the tool does not modify the project or discuss any behavioral traits such as permissions 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 two concise sentences. The first sentence states the main purpose, and the second adds output details. 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 2 optional parameters, no annotations, and no output schema, the description adequately covers the analysis categories and the return type (grade and recommendations). It could mention that results are dependent on the project state, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for both parameters with clear descriptions. The tool description does not add significant meaning beyond what the schema already provides, 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 clearly states the tool gets a 'comprehensive health score' and lists exactly what it analyzes (configuration, code quality, structure, documentation, testing readiness), with a specific output (grade A-F with recommendations). This distinguishes it from siblings 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 checking project health but gives no explicit guidance on when to use this tool versus alternatives like 'analyze' or 'review'. No when-not or alternative tool mentions.
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 fully disclose behavior. It only states 'Get help' without indicating whether the operation is read-only, what side effects exist, or how the help content is retrieved. This is insufficient for an agent to assess safety.
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 purpose. Every word is necessary, with no fluff or redundancy.
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 simplicity of the tool, the description should mention what the output format is (e.g., text, structured info) and the default behavior when no topic is specified. Since no output schema is provided, this information is missing, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'topic' has 100% schema coverage with enum values and a brief description. The description adds no extra meaning beyond the schema, which is adequate but not enhanced.
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 get help about StackGuide tools and their usage. It uses a specific verb and resource, distinguishing it from sibling tools that focus on specific functions. However, it could be more specific about the type of help returned.
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 sibling tools like 'docs' or 'setup'. It does not mention exclusions or alternative tools for more specific help.
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 and hooks.
| 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 must fully disclose behavior. It only mentions auto-detection and scaffolding, omitting side effects (e.g., overwriting files), error conditions, or permission requirements. For a tool with 10 parameters, this is insufficient.
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 fluff. The key action is front-loaded, and additional context is provided efficiently.
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?
Despite having 10 parameters and no output schema, the description is minimal. It fails to explain behavior for parameters like 'action' or 'integrations', or what happens on re-initialization. The tool's complexity demands more detail.
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 documented in the schema. The tool description adds no extra meaning beyond the schema. 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 initializes a project with a specific workflow, auto-detects stack, and scaffolds a directory. The verb 'Initialize' and resource 'project with StackGuide TDD workflow' are specific and distinct from siblings like 'setup' 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?
No explicit guidance on when to use this tool versus alternatives like 'setup' or 'generate'. The description does not mention exclusions or suitable contexts, leaving the AI agent without decision-making support.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to state whether the tool is read-only, destructive, or has any side effects. The term 'manage' implies potential mutation, but it is ambiguous.
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 clear sentence with no redundant text. It could be slightly more structured (e.g., listing actions), but it is efficient and front-loaded.
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 absence of an output schema, the description should elaborate on return values or behavior for each action. It provides enough to understand the tool's purpose but lacks details for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds minimal extra meaning beyond the schema, primarily reiterating the action names. Thus, it meets the baseline for high schema coverage.
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 with specific actions: list, search, or get architecture patterns and solutions. This distinguishes it from siblings like workflow or health.
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 does not specify prerequisites, limitations, 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.
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 carries full burden. It states the tool uses 'pattern matching', detects issues, and returns a score (0-100) and detailed report. This gives reasonable insight into behavior, but does not mention side effects, auth requirements, or limitations such as scope of pattern matching (e.g., only common patterns).
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 sentences, front-loaded with the core action and purpose. Every sentence adds value: first sentence defines what it does, second lists detected categories, third describes output and input types. No redundant or filler content.
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, the description adequately explains return values (score and detailed report). It covers the range of inputs (files, URLs, projects) and focuses. However, it does not clarify behavior when no parameters are provided (e.g., whether it defaults to a specific mode or requires at least one).
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 repeats the parameter purposes (files, URLs, projects, focus) but adds no new semantic information beyond what the schema already provides. For example, 'focus' enum values are listed in the description but already elaborated in the schema's description field.
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 'Analyze code for issues using pattern matching' and specifies the resource as code. It lists four categories of issues (security, performance, coding standards, architecture) which distinguishes it from generic tools. However, it does not explicitly differentiate from the sibling 'analyze' tool, which could overlap in 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?
The description implies usage for code review with specific focus areas and input types (files, URLs, projects). It provides some guidance on when to use (to detect various issues) but lacks explicit exclusions or alternatives. No mention of when not to use this tool vs. siblings like 'workflow' or 'health'.
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 are provided, so the description must disclose behavioral traits. It does not clarify if actions like 'select' are mutating or merely retrieving, nor any side effects or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the verb 'Manage'. It is concise and easy to parse, though it could be slightly more structured.
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 no output schema, the description is barely adequate. It does not explain return values, effects of actions, or project-scope details beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema (100% coverage), so the description adds minimal extra meaning beyond listing actions. Action names are repeated, but no additional parameter nuances are provided.
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 rules and lists four actions (list, search, get, select). However, it does not differentiate from the sibling tool 'custom_rule', leaving ambiguity.
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 managing rules via listed actions, but provides no guidance on when to avoid this tool or use alternatives like 'custom_rule' or 'knowledge'.
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 provided, so the description carries full burden. It does not disclose side effects, persistence, or safety considerations (e.g., destructive nature, auth requirements, idempotency).
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 fluff, efficiently conveys the core purpose and key feature (auto-detection).
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 and no output schema, the description is too brief to cover parameter interactions, expected outcomes, or workflow. It adequately states the tool's role but leaves gaps in understanding full 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 coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema (only hinting at 'path' and 'type' auto-detection). No extra context 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 verb 'configure' and resource 'StackGuide', and mentions auto-detection. However, it does not distinguish from sibling tools like 'init' or 'config', which may overlap in 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?
No guidance on when to use this tool versus alternatives (e.g., init, config, workflow). The description lacks context for prioritization or exclusion.
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 and commands 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") | |
| action | No | Action to perform | |
| category | No | Filter list by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'lazy loading' to save tokens, which hints at efficient loading, but does not specify what happens on invocation (e.g., does it execute the workflow or just manage components?). The action parameter implying both listing and loading is not clarified. The behavioral description is insufficient.
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, covering the core idea of lazy loading and the five roles. It is front-loaded with the key purpose, but does not structure information for quick scanning of parameters or usage.
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 three parameters (two with enums), no output schema, and no annotations, the description should provide enough context to use the tool correctly. It omits how to start the workflow or the difference between listing and loading. The roles are mentioned but not connected to parameters, leaving the function ambiguous.
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 the concept of 'loading on demand' and the five roles, but does not tie this directly to parameters like 'name' or 'action'. It provides minimal extra meaning beyond the schema's enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'TDD agentic workflow with lazy loading' and mentions loading agents, skills, hooks, and commands, which gives a clear verb-resource pair. The mention of five roles (Intake, Planner, Implementer, Verifier, Releaser) provides some distinction from sibling tools like 'agent' or 'generate', but does not explicitly differentiate from all siblings.
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 does not provide guidance on when to use this tool versus alternatives. It lacks explicit context for when to invoke the workflow or how it differs from tools like 'agent' or 'init'. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v4.1.6agentanalyzeconfigcontextcursorcustom_ruledocsgeneratehealthhelpinitknowledgereviewrulessetupworkflowSeveral tools have overlapping purposes: 'workflow' and 'agent' both handle TDD workflow actions; 'init' and 'setup' both configure the project; 'health', 'analyze', and 'review' all perform analysis. While descriptions provide some differentiation, an agent may still confuse similar tools.
Tool names are a mix of verbs (generate, init, analyze, help, setup, review) and nouns (workflow, health, agent, context, rules, knowledge, cursor, docs, config, custom_rule). 'custom_rule' uses an underscore while all others are single words, showing no consistent naming pattern.
With 16 tools, the server is slightly above the typical 3-15 range but still well-scoped for its broad feature set covering workflow, analysis, code generation, and configuration management. Each tool serves a clear purpose, and none seem redundant.
The tool set covers major aspects of a development assistant: project initialization, workflow management, code generation, health analysis, code review, rule management, documentation, and configuration. Minor gaps exist (e.g., no explicit deployment or testing automation), but overall it is comprehensive for its domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
Context engineering for AI coding agents: product context, project missions, and 360 memory.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
Project registry, behavioral specs, and engineering threads for AI coding agent workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/taimiralain/StackGuide-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server