This server provides access to a curated directory of 100+ engineering tools via 3 tools:
search_engineering_matrix: Search for tools by name, tag, or use case (e.g., "python linter", "ci cd"). Supports multi-word queries, optional category filtering, and result limits.
list_categories: Browse all 6 tool categories (languages, frontend, backend, databases, devops, tooling) with tool counts for each.
get_repository_boilerplate: Retrieve ready-to-use starter files for a specific tool or framework (e.g., TypeScript, React, Docker, FastAPI, Rust). Free tier includes 5 boilerplates; Pro unlocks all 33+.
Allows searching for and retrieving boilerplate files for Docker projects.
Allows searching for and retrieving boilerplate files for ESLint configurations.
Allows searching for and retrieving boilerplate files for Express projects.
Allows searching for and retrieving boilerplate files for FastAPI projects.
Allows searching for and retrieving boilerplate files for Fastify projects.
Allows searching for and retrieving boilerplate files for GitHub Actions workflows.
Allows searching for and retrieving boilerplate files for Jest testing setups.
Allows searching for and retrieving boilerplate files for Kubernetes projects.
Allows searching for and retrieving boilerplate files for MongoDB projects.
Allows searching for and retrieving boilerplate files for Next.js projects.
Allows searching for and retrieving boilerplate files for Node.js projects.
Allows searching for and retrieving boilerplate files for pnpm package manager configurations.
Allows searching for and retrieving boilerplate files for PostgreSQL projects.
Allows searching for and retrieving boilerplate files for Prettier configurations.
Allows searching for and retrieving boilerplate files for Prisma projects.
Allows searching for and retrieving boilerplate files for Python projects.
Allows searching for and retrieving boilerplate files for React projects.
Allows searching for and retrieving boilerplate files for Redis projects.
Allows searching for and retrieving boilerplate files for Ruff configurations.
Allows searching for and retrieving boilerplate files for Rust projects.
Allows searching for and retrieving boilerplate files for Supabase projects.
Allows searching for and retrieving boilerplate files for Svelte projects.
Allows searching for and retrieving boilerplate files for Tailwind CSS projects.
Allows searching for and retrieving boilerplate files for Terraform projects.
Allows searching for and retrieving boilerplate files for TypeScript projects.
Allows searching for and retrieving boilerplate files for Vercel deployments.
Allows searching for and retrieving boilerplate files for Vite projects.
Allows searching for and retrieving boilerplate files for Vitest testing setups.
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., "@engineering-matrix-explorer Give me a Docker boilerplate"
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 gives Claude (or any MCP-compatible AI) instant access to a curated matrix of 100+ engineering tools — search by name, tag, or use case, browse by category, and pull ready-to-use boilerplate files for 30+ popular stacks.
Free: search + 5 boilerplates (TypeScript, Python, React, Docker, Node.js) | Pro $15: all 33 boilerplates unlocked | Bundle $29: 3 MCP servers
Three tools, zero configuration:
search_engineering_matrix — find tools by name, tag, or use case. Multi-word queries work great.
"python linter" → Ruff, ESLint
"ci cd" → GitHub Actions
"database sql" → PostgreSQL, Prisma, Supabase
"container" → Docker, Kuberneteslist_categories — browse all 6 categories with tool counts: languages, frontend, backend, databases, devops, tooling.
get_repository_boilerplate — get starter files for a tool in one shot. Supports: TypeScript, Python, Node.js, React, Next.js, FastAPI, Docker, GitHub Actions, Rust, Go.
Related MCP server: stacksfinder-mcp
npx @engineeringmatrixexplorer/engineering-matrix-explorerOr install globally:
npm install -g @engineeringmatrixexplorer/engineering-matrix-explorerOpen your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add:
{
"mcpServers": {
"engineering-matrix-explorer": {
"command": "npx",
"args": ["-y", "@engineeringmatrixexplorer/engineering-matrix-explorer"]
}
}
}Restart Claude Desktop. You'll see the tools appear automatically.
claude mcp add engineering-matrix-explorer -- npx -y @engineeringmatrixexplorer/engineering-matrix-explorerOnce connected, try asking Claude:
"What TypeScript linting tools are available?"
"Give me a Docker boilerplate for my new project"
"What's in the devops category?"
"Find me a fast Python web framework"
"Set up a GitHub Actions CI config for my repo"
Category | Tools |
Languages | TypeScript, Python, Rust, Go |
Frontend | React, Next.js, Vue, Svelte, Tailwind CSS, Vite |
Backend | Node.js, Fastify, Express, FastAPI |
Databases | PostgreSQL, Redis, MongoDB, Prisma, Supabase |
DevOps | Docker, Kubernetes, GitHub Actions, Terraform, Vercel |
Tooling | ESLint, Prettier, Ruff, Vitest, Jest, pnpm |
I build custom MCP servers for companies and dev teams — internal tool search, docs integrations, API connectors, anything you want Claude to do that it can't do out of the box.
If you're interested: elias.nyc.rentals@gmail.com
Node.js 18+
MIT
Get starter boilerplate files for a specific tool or framework
| Name | Required | Description | Default |
|---|---|---|---|
| toolName | Yes | Tool name e.g. 'TypeScript', 'FastAPI', 'Docker' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must reveal behavioral traits. It only says 'Get starter boilerplate files' with no mention of side effects, error handling (e.g., unknown tool), or whether files are generated/static. 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?
Single sentence with no fluff. Every word is necessary. Front-loaded with verb and resource.
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 tool with one parameter, the description is adequate but lacks detail on what the boilerplate files contain or how they are returned (e.g., as a download or inline). No output schema exists to supplement.
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 has 100% coverage with a description for toolName that includes examples. The tool description adds no additional meaning beyond what the schema already provides, so 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?
Description clearly states the action (Get) and resource (starter boilerplate files) and specifies it's for a specific tool or framework. It distinguishes from sibling tools list_categories and search_engineering_matrix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied: call this when you need starter files for a tool. No alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all engineering tool categories with tool counts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the tool lists categories with counts, implying a read-only operation. However, it does not explicitly note the absence of side effects or any additional 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 of 7 words, conveying the essential information with no wasted text. It is front-loaded and perfectly concise for the tool's 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 tool's simplicity (no parameters, no output schema, no annotations), the description provides sufficient information. It states exactly what the tool does and what it returns, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and according to calibration guidelines, a score of 4 is baseline. The description adds no parameter details since none exist, but this is expected and not a deficiency.
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 a clear verb ('List'), a specific resource ('all engineering tool categories'), and an outcome ('with tool counts'). It distinguishes from sibling tools like 'get_repository_boilerplate' and 'search_engineering_matrix' which serve different purposes.
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. The purpose is straightforward and divergence from siblings is implied, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for engineering tools by name, tag, or use case. Supports multi-word queries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query e.g. 'python linter', 'react', 'ci cd' | |
| categoryFilter | No | Optional category id to restrict search | |
| limit | No | Max results (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior beyond the basic function. It only mentions the search fields and multi-word support, but does not specify behavior like case sensitivity, fuzzy matching, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences are perfectly concise and front-loaded: the first states the core purpose, and the second adds a key detail. 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?
The description is adequate for a simple search tool, but lacks details about the output format or how the category filter works. With no output schema, some additional context would be beneficial.
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 three parameters. The description adds minimal extra meaning beyond the schema examples, such as 'supports multi-word queries,' which is already implied by 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?
The description clearly states the tool searches for engineering tools by name, tag, or use case, and supports multi-word queries. It distinguishes this search tool from siblings that deal with boilerplate code or category listings.
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, such as when to use list_categories instead. It only states what the tool does.
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.2get_repository_boilerplatelist_categoriessearch_engineering_matrixEach tool targets a distinct function: retrieving boilerplate, listing categories, and searching the matrix. No overlap in purpose.
All tools follow a consistent verb_noun pattern using snake_case, making their actions and targets clear.
With 3 tools, the surface is somewhat minimal but covers the core exploratory functions for an engineering matrix. Could benefit from a tool to get details on a specific tool, but not a major issue.
The set provides search, categorization, and boilerplate retrieval, which are central to exploring a matrix. Missing a direct 'get tool details' function, but search may cover that need.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and get recommendations from your own saved catalog of developer tools and services.
Search 5000+ software tools with structured, labelled facts. No pay-to-rank.
Software component catalog: search your org's services, docs, APIs, dependencies, and ownership.
AI-powered SaaS tool discovery API. Search 150+ curated business tools and get recommendations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/officechbusinessservices-creator/engineering-matrix-explorer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
