Build Runner MCP Server

by egn88

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools cleanly separate by ecosystem and build phase: Java build/install/compile/test versus Node build/test/typecheck. The only real ambiguity is compile_project vs build_project, since compilation is normally part of a build, but the descriptions clarify that compile focuses on diagnostics while build produces artifacts.
Naming Consistency3/5
Naming is mixed: Java tools mostly follow verb_project (build_project, install_project, compile_project), while Node tools follow node_verb (node_test, node_build, node_typecheck). run_tests breaks the Java pattern by using a generic verb instead of something like test_project, and set_java_version follows yet another style.
Tool Count5/5
Nine tools is well-scoped for a multi-language build runner. Each tool covers a meaningful build, test, install, detect, or environment-management action without feeling padded or redundant.
Completeness4/5
The surface covers the core Java and Node.js workflows: detection, building, compiling, testing, installing for Java, and type checking for TypeScript projects. Minor gaps like a Node install/publish command or a generic clean task are absent, but agents can still complete typical build-and-test workflows.
Average 3.6/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the package managers but not whether dependencies are installed first, what side effects occur (e.g., output artifacts), what the return behavior is, or whether the operation is safe. For a build operation, this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence with no filler. It front-loads the core action and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description is moderately complete: it identifies the operation and package managers, and the schema covers parameters. However, it omits context about whether a specific script must exist, whether installation happens first, and what success/failure looks like, so an agent may still need to probe behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds a little extra meaning by reaffirming the accepted package managers (npm, pnpm, yarn) and the Node.js/TypeScript context, but it does not go beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Build') and resource ('Node.js/TypeScript project'), and names the supported package managers. It is distinguishable from siblings like set_java_version or node_test by its language and build focus, but it does not explicitly contrast itself with the more generic build_project or compile_project siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to choose this tool over build_project, compile_project, or install_project. It implies usage for Node.js/TypeScript builds but never states exclusions or alternatives, leaving the agent to infer selection criteria from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It adds that the tool returns build artifacts and duration, but does not disclose side effects such as writes to target directories, test execution behavior, or failure modes; these remain mostly implied by 'build/package'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The primary action and return information are front-loaded, and every phrase adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core operation and a basic return summary, but with no output schema and no annotations it does not fully cover behavior such as how the build tool is selected, output location, or when to prefer a sibling. It is minimally sufficient but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description adds no parameter-level detail beyond the supported build tools, which fits the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear action (build/package) and resource (Java project via Maven/Gradle), plus what is returned. However, it does not explicitly differentiate from sibling compile_project or install_project, so the distinction is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over siblings like compile_project, install_project, or detect_project. There are no exclusions, prerequisites, or alternative routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does add useful output behavior by stating that the tool returns structured error/warning information, but it does not disclose side effects such as writing build artifacts, downloading dependencies, or the time/network implications of compilation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. The key action and build systems are stated first, and the output behavior is included without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is too sparse to be fully actionable. It does not explain how the tool chooses between Maven and Gradle, what the structured error/warning output contains, or how this tool relates to build_project and install_project, so an agent lacks important context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters clearly. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles a Java project using Maven or Gradle, which is a specific verb and resource. However, it does not distinguish compile_project from sibling tools like build_project or install_project, so the differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to compile a Java Maven/Gradle project. It gives no explicit guidance about when not to use it, no alternatives, and no mention of prerequisites like detect_project or set_java_version, leaving the choice among sibling build tools to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that results are returned in structured form, which is useful behavioral information. However, with no annotations, it does not mention potential side effects such as coverage artifacts, prerequisites like installed dependencies, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with the core action first and the return behavior second. There is no filler, repetition of schema fields, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no annotations and no output schema, this description is too thin. It omits when to use this versus run_tests, what the structured results contain, and how framework/package-manager auto-detection behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all six parameters with 100% coverage, so the baseline is 3. The description adds little beyond the schema, and it only indirectly references the framework options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Run tests') and a specific resource ('Node.js/TypeScript project'), and narrows the scope to Jest, Vitest, or Mocha. It does not explicitly contrast itself with the generic sibling run_tests, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Node.js/TypeScript scope and listed frameworks give implied guidance about when to use the tool. However, it does not explicitly explain when to choose it over the overlapping sibling run_tests 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It is transparent about what the tool detects and which project types are supported, but it does not disclose what happens for unsupported projects, whether the operation is read-only, or what the success/failure response looks like. Given the simplicity of a detection tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first states the core action and object; the second lists supported ecosystems. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter detection tool, the description covers the main purpose and scope. However, with no output schema and no annotations, it lacks detail on expected return values and behavior for unsupported project types. The gaps are notable but not severe for a simple detection operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the sole parameter (projectPath). The description adds context about supported ecosystems, which implies valid project-root paths, but does not add additional parameter-specific semantics beyond that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Detect') with a clear resource ('project type, build system, test framework, and configuration'). It also enumerates supported ecosystems (Maven, Gradle, npm, pnpm, yarn), which distinguishes it from sibling build/test/install tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance about when to use this tool versus alternatives. It implies usage as a pre-step to build/test tools, but there is no statement like 'use before build_project' or 'for unsupported project types, use X'. The supported-ecosystem list gives some context but not direct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'tsc --noEmit' is a meaningful disclosure: the tool performs a type check and does not emit compiled output. However, it does not explain failure behavior, exit codes, whether dependencies must be installed first, or what happens when type errors are found, leaving transparency partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the key action is front-loaded immediately. Every word contributes: the operation, the target resource, and the command-line mode.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents the parameters and the operation is simple, so an agent can invoke it with minimal risk. However, with no annotations, no output schema, and no usage-guidance context, some gaps remain around expected outcomes and when to prefer this over sibling tools. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline applies since the schema already documents both projectPath and packageManager. The description adds no extra meaning beyond tying the action to a TypeScript project; it does not elaborate on path expectations, package-manager resolution, or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Type check') and resource ('a TypeScript project'), and names the exact mechanism ('tsc --noEmit'). This clearly distinguishes it from sibling tools like build_project, compile_project, and node_test, because type-checking without emit is a distinct validation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over its siblings, such as compile_project, node_test, or run_tests. The description implies its use only through the verb 'type check' and provides no exclusions, prerequisites, or alternative routing. An agent must infer usage context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the return shape ('structured test results with failures and stack traces'), which is useful, but it does not mention potential side effects of running arbitrary test code (e.g., executing project code, downloading dependencies, or producing build artifacts). It is not misleading, just incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action and scope, the second states the return value. Every word earns its place, with no redundant detail or complex structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides only a high-level result summary. It does not clarify prerequisites (e.g., whether the project must already be built), how Maven vs Gradle is detected, or timeout/performance expectations. The 7 parameters are well documented in the schema, but the operational context is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter already has a descriptive comment, so the description does not need to add parameter details. It adds no additional meaning beyond the schema, keeping it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and resource ('tests for a Java project'), and names the build tools (Maven or Gradle). It clearly distinguishes from Node-focused siblings like node_test and from build/compile tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — for Java projects using Maven/Gradle, not Node projects — but does not explicitly state when not to use it or how it compares to alternatives like build_project, compile_project, or detect_project. Usage context is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state the underlying commands and the effect on the local Maven repository, which is useful. However, it does not mention side effects not captured elsewhere, such as test execution defaults, dependency building behavior, or overwriting existing local artifacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and target repository are stated first, and the multi-module capability is added in the second sentence. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, supported build tools, and multi-module capability, and the schema covers all parameters. Still, with no output schema and no annotations, it leaves some contextual gaps, such as what success/failure output looks like and how Java version selection is applied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter schema already documents all 6 parameters. The description adds some context around multi-module support via the -pl flag, but it does not materially extend the meaning of the parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action — install a Java project to the local Maven repository — and names the exact mechanisms (mvn install / publishToMavenLocal). This distinguishes it from sibling tools like build_project and compile_project, which do not install artifacts to a local repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is appropriate: when a Java project needs to be installed locally via Maven or Gradle. It also notes multi-module support, but it does not explicitly contrast the tool with siblings such as build_project or run_tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the mechanism (SDKMAN), available versions, and the intended timing, but it does not describe side effects, persistence of the switch, or failure behavior. This is a partial but not complete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that leads with the action, then gives the mechanism, timing, and a list of valid values. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers purpose, mechanism, valid inputs, and usage timing. Return values are not described and there is no output schema, but for a switch command this is a minor gap; an agent can likely infer success from the command outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by enumerating the exact available versions, which is more specific than the schema's examples. It doesn't add anything about projectPath, but the schema already explains it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Switch Java version') with a clear method ('using SDKMAN') and temporal context ('before running commands'). This clearly distinguishes it from sibling build/test tools, which address different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'before running commands', giving the agent a clear when-to-use signal. It does not mention when-not-to-use or alternatives, but no alternative Java-version-switching tool exists among the siblings, so exclusions are unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![build-runner-mcp MCP server](https://glama.ai/mcp/servers/egn88/build-runner-mcp/badges/card.svg)](https://glama.ai/mcp/servers/egn88/build-runner-mcp)

Score Badge

Copy to your README.md:

[![build-runner-mcp MCP server](https://glama.ai/mcp/servers/egn88/build-runner-mcp/badges/score.svg)](https://glama.ai/mcp/servers/egn88/build-runner-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/egn88/build-runner-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server