harness-bridge

Overview Schema Source Related Servers Score Discussions Admin

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Each tool has a distinct specialized purpose—reviewing code, explaining code, critiquing plans, planning performance work, and implementing changes. However, codex_query is a catch-all that overlaps with all the other tools, which could create some selection ambiguity.
Naming Consistency4/5
All tools share the codex_ prefix and use verb-oriented names, making the pattern easy to follow. The deviations are codex_query, which lacks an object, and codex_plan_perf, which uses an awkward abbreviation instead of a clear noun like performance.
Tool Count5/5
Six tools is a well-scoped count for a Codex bridge. Each tool covers a meaningful developer workflow without unnecessary redundancy, and the set feels neither thin nor bloated.
Completeness4/5
The tool set covers the major interaction modes with Codex: reviewing, explaining, planning, performance analysis, implementation, and general Q&A. The generic codex_query prevents dead ends, though a security-specific review or similar niche tool could be added without much effort.
Average 3.6/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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 present, so the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, whether it can make changes, how it interacts with the working directory, or what kind of output to expect. For a Codex-powered tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose front-loaded and supporting use cases in a second sentence. There is no redundant or filler content, though it is not maximally information-dense.
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 is adequate for a read-oriented explanation tool: it states purpose and typical use cases, while the schema covers parameter meaning and defaults. However, with no annotations and no output schema, the agent is left to infer return behavior and safety characteristics, and the sibling tools are not differentiated.
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 80%, so most parameters are already documented in the schema. The description itself adds no parameter-level detail and does not clarify the undocumented workingDirectory parameter, but it does not need to repeat what the schema already provides. Baseline 3 is appropriate.
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 action ('deeply explain') and the resource ('code, logic, or architecture'), making the tool's purpose immediately understandable. It does not explicitly contrast it with siblings like codex_review_code, but the wording implies explanation rather than review, critique, or implementation.
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 provides concrete use cases: 'understanding unfamiliar code, onboarding, or documenting complex systems.' This gives the agent clear context for when to select this tool, though it does not explicitly say when not to use it or name alternative tools.
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 disclosure burden. It discloses the output behavior—identifying bottlenecks and proposing ranked optimizations with expected impact—which suggests a non-mutating planning task, but it never explicitly rules out writing files, invoking side effects, or requiring special permissions.
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 focused sentences with no wasted words. It front-loads the purpose and then adds the key output details, making it easy for an agent to scan and understand.
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 explains the purpose and output adequately, while the schema covers most parameters. However, with no annotations, no output schema, and sibling tools present, the description leaves usage-selection and operational/side-effect context implicit, so it is not fully complete.
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 description adds little parameter-level meaning beyond the high-quality schema, which already documents target, context, metrics, threadId, and constraints. Since schema description coverage is 83%, the baseline of 3 is appropriate; only workingDirectory lacks a schema description.
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 and resource: analyze performance and create an improvement plan. It further distinguishes itself by naming outputs like bottlenecks and ranked optimizations, making it distinguishable from the code-review, query, explain, and implement 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 implies a performance-analysis use case but provides no explicit guidance on when to choose this tool over alternatives such as codex_review_plan or codex_query. There are no exclusions, prerequisites, or criteria for picking this tool versus the other Codex siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It only says 'ask a question or give it a task,' which is ambiguous about whether Codex may execute code, modify files, or have side effects. It also does not mention thread continuation behavior or what the response contains, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose is front-loaded, and the usage guidance is placed efficiently after the action. Every sentence 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?
The description covers the high-level purpose and typical use cases, but because there is no output schema and no annotations, it misses important context: what a call returns, whether threadId allows continuing conversations, and whether 'give it a task' can lead to file mutations. It is adequate for a general query tool but not fully complete.
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 parameters, including the model override caveat and threadId semantics. The description adds little beyond saying the prompt is 'the question or task,' which is consistent with the schema; baseline 3 is appropriate.
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 a specific action ('Ask OpenAI Codex a question or give it a task') and identifies the resource. It suggests general use cases like 'second opinion' and 'exploring unfamiliar code,' but does not explicitly distinguish itself from siblings such as codex_explain_code or codex_review_code, so it falls short of a 5.
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 provides clear contexts for use: 'second opinion,' 'unfamiliar code,' and 'different model's perspective.' It does not, however, state when not to use it or explicitly name alternatives, so the guidance is present but lacks exclusions.
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 behavioral disclosure. It does state what the tool produces—critique of gaps, risks, edge cases, improvements—but it does not mention whether the operation is read-only, whether it only returns text, or any side effects or prerequisites.
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 sentence, front-loaded with the action and resource, and every clause adds useful information. No filler or repetition of the tool name or title.
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 is enough to understand the core purpose, but with no annotations and no output schema, it leaves out useful context such as return format/behavior and how this tool relates to sibling codex_plan_perf. The schema handles parameter documentation, so the remaining gap is guidance on alternatives and output expectations.
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 80%, so the baseline is 3. The description's mention of 'implementation plan' aligns with the required plan parameter but adds little semantic detail beyond the schema's own descriptions for threadId, constraints, and codebasePath.
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 specific verb ('critique') and identifies the resource ('implementation plan'), and lists concrete outcomes: gaps, risks, missing edge cases, and improvements. It clearly distinguishes from code review and explanation tools, though it does not explicitly differentiate from the sibling codex_plan_perf, which also targets plans.
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 intended use is implied: bring an implementation plan to get a critical review. However, it provides no explicit when-to-use guidance, no exclusions, and no alternative routing such as 'use codex_plan_perf for performance-specific plan review.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly warns that the tool modifies the codebase and states that it returns a summary of changes, which are the most important behavioral characteristics for an agent to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that cover purpose, a safety warning, and the return type. The WARNING is front-loaded and the most critical information is easy to notice. A little more detail about alternatives or parameters could be added, but the current length is appropriate.
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?
Given that there are no annotations and no output schema, the description covers the essential context: what the tool does, that it mutates the codebase, and what it returns. It falls slightly short by not mentioning when to choose this tool over siblings or clarifying workingDirectory, but it is largely complete for safe 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?
The description adds no parameter-level detail beyond the input schema, but the schema already covers 75% of parameters with meaningful descriptions for task, model, and threadId. The workingDirectory parameter lacks a schema description and is not compensated for in the tool description.
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's action: ask Codex to implement a feature, fix a bug, or make code changes. It doesn't explicitly distinguish itself from the sibling review/query/plan tools, but the verb 'implement' and focus on code modification make the purpose clear.
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 the tool should be used when the goal is to modify code, which is helpful context. However, it provides no explicit guidance on when not to use it or how it compares to sibling tools like codex_review_code or codex_query.
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. It states that the tool invokes Codex and 'Returns specific, actionable feedback', which covers the primary behavior and output. However, it does not mention side effects, whether the tool modifies files, prerequisites like a git repository, or external-service considerations, leaving some behavioral ambiguity.
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 tight sentences with the core purpose front-loaded and input options compressed efficiently. Every phrase earns its place and there is no fluff or repetition.
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?
Given no annotations and no output schema, the description plus schema covers the target formats, optional context, focus areas, thread continuation, and the return type at a high level. The main gap is the undocumented workingDirectory parameter, though its meaning is reasonably inferable from its name.
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 high at 80%, so the schema already documents most parameters. The description mostly restates the target options already present in the schema and adds no meaningful detail about workingDirectory or other optional parameters.
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 states a specific verb and resource: 'Ask Codex to review code', and clarifies what can be reviewed (git diff range, file paths, snippet) and what is returned (specific, actionable feedback). It is clear from 'review' how this differs from siblings like codex_explain_code, though it does not explicitly name them.
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 communicates the context clearly: use this tool when you want Codex to review code, and it tells the agent what to supply ('Provide a git diff range, file paths, or a code snippet.'). It does not explicitly mention alternatives or when-not-to-use, so it stops short of a 5.
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

harness-bridge MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![harness-bridge MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/rbutera/harness-bridge/badges/card.svg)](https://glama.ai/mcp/servers/rbutera/harness-bridge)

Score Badge

Copy to your README.md:

[![harness-bridge MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/rbutera/harness-bridge/badges/score.svg)](https://glama.ai/mcp/servers/rbutera/harness-bridge)

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/rbutera/harness-bridge'

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