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., "@stack-advisor I'm building a real-time chat app"
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.
An MCP server that recommends tech stacks for your project. Describe what you're building and get a recommended stack with reasoning, tradeoffs, and what each layer should use.
recommend_stack — describe your project, get 1-3 ranked stack recommendations each with:
Full layer breakdown (language, frontend, backend, database, devops, testing)
Why this stack fits your use case
Tradeoffs to be aware of
What it's not good for
list_stacks — see all available stack templates
Related MCP server: project-scaffold
"I'm building a SaaS dashboard for small businesses"
"What stack should I use for an AI/ML API?"
"Best stack for a cross-platform mobile app?"
"I need a high-performance Go API for a microservice"
"What are the tradeoffs of a serverless edge architecture?"
{
"mcpServers": {
"stack-advisor": {
"command": "npx",
"args": ["-y", "@engineeringmatrixexplorer/stack-advisor"]
}
}
}claude mcp add stack-advisor -- npx -y @engineeringmatrixexplorer/stack-advisorStack | Best for |
Modern TypeScript Web App | SaaS, dashboards, fullstack apps |
Python AI/ML Backend | AI APIs, ML inference, data pipelines |
High-Performance Go API | Microservices, high-traffic APIs |
React SPA + Node Backend | SPAs, JS-heavy frontends |
Enterprise Node.js API | Large teams, structured codebases |
Serverless Edge App | Global low-latency, Cloudflare Workers |
Mobile App (React Native) | iOS + Android cross-platform |
Static Site / Content Site | Blogs, docs, marketing, SEO |
Node.js 18+
This server is also available as part of a bundle with engineering-matrix-explorer and snippet-vault.
MIT
List all available stack templates with their tags
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. The verb 'list' implies a read-only operation with no side effects, which is sufficient. It does not mention potential pagination or ordering, but given the simplicity, it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action 'List' and includes essential qualifiers. Every word serves a purpose, making it highly concise and effective.
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 should explain the return value. It mentions 'stack templates with their tags' but does not specify other fields like name or ID, leaving some ambiguity about the full output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is trivially 100%. The description does not need to add parameter meaning, and the baseline score of 4 is appropriate as it does not detract from understanding.
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 'list' and the resource 'stack templates' with scope 'all available' and includes 'with their tags', which precisely defines the tool's function and distinguishes it from the sibling 'recommend_stack'.
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 clear context for when to use the tool (when a listing of all stack templates is needed), but lacks explicit exclusions or alternatives such as noting that 'recommend_stack' should be used for personalized recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe your project and get 1-3 recommended tech stacks with reasoning, tradeoffs, and what each layer should use.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | What are you building? e.g. 'a SaaS dashboard for small businesses', 'a real-time chat API', 'a mobile app for food delivery' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It discloses that the tool returns 1-3 recommendations with reasoning, tradeoffs, and layer suggestions. However, it does not mention any potential side effects, authorization requirements, rate limits, or other constraints that might affect usage.
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, well-structured sentence that conveys the core function without any superfluous words. It is concise and immediately informative.
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 (one parameter, no output schema, a single sibling), the description is complete. It explains the input needed, the process (recommendation generation), and the expected output (1-3 stacks with reasoning, tradeoffs, and layer suggestions). No further detail is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description and example for the only parameter 'description'. The tool description reinforces the parameter's purpose. Since schema coverage is high, the baseline is 3, and the tool description adds marginal value beyond the schema by hinting at the output structure.
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 function: given a project description, it returns 1-3 recommended tech stacks with reasoning, tradeoffs, and per-layer suggestions. This distinguishes it from the sibling tool 'list_stacks', which likely merely lists available stacks without recommendations.
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 implicitly tells the user when to use this tool: when they need tech stack recommendations for a project. It does not explicitly exclude use cases or mention when not to use, but the context is clear and the sibling tool provides an alternative for simple listing.
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.
v1.0.2list_stacksrecommend_stackThe two tools have clearly distinct purposes: one lists available stack templates, the other provides personalized recommendations. There is no overlap or ambiguity.
Both tool names follow the same verb_noun pattern in snake_case (list_stacks, recommend_stack), maintaining perfect consistency.
With only 2 tools, the surface is too thin for a 'stack advisor' server. Users likely need additional functionality like searching, filtering, or viewing stack details.
Obvious gaps exist: no way to inspect individual stack templates, search by tags, compare stacks, or manage stacks. The surface is severely limited for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server aggregating developer infrastructure deals, free tiers, and startup programs
A MCP server built for developers enabling Git based project management with project and personal…
Search 77,000+ MCP servers ranked by real adoption data to find the right one for any task.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/officechbusinessservices-creator/stack-advisor'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
