Harness MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: status for overview, get_spec for reading the spec, list_pending for pending changes, verify for code comparison, reverse for inferring from code, propose_structure/change for generating proposals, sync_design_system for design integration, configure for settings, checkpoint for rollbacks. No overlap.
Naming Consistency5/5
All tools follow the 'harness_verb_noun' pattern with consistent snake_case. Single-word verbs like 'status', 'verify', 'reverse', 'configure', 'checkpoint' are acceptable and uniform.
Tool Count5/5
10 tools is well-scoped for a harness management domain—enough to cover essential operations without being bloated or too few.
Completeness4/5
Covers viewing, reading, proposing, verifying, reversing, syncing, configuring, and checkpointing. Missing explicit tools for approving/rejecting pending changes, which is a minor gap but most workflows are supported.
Average 3.3/5 across 10 of 10 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 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
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?
With no annotations, the description must fully disclose behavior. It only lists the actions without side effects, assuming idempotency, or destructive behavior. No mention of what happens on create or restore.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but omits necessary details. It front-loads the actions but lacks structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely incomplete given the 4 parameters, no annotations, and no output schema. It fails to provide context on what a checkpoint is, how parameters interact, or expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%. The description does not explain parameters beyond the schema. For example, what label is used for, what checkpoint_id refers to, and the implications of each action value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions three actions (create, list, restore) but uses the vague phrase 'take a rollback point' for create. It does not specify that the resource is called a checkpoint, nor does it differentiate from sibling 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 guidance on when to use this tool vs alternatives like harness_reverse. The description does not explain when to create, list, or restore.
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?
With no annotations, the description must disclose behavioral traits. It implies a read operation but does not state whether it is read-only, what permissions are needed, or if it has side effects. The description is too minimal for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is somewhat informal and starts with a colon. It conveys information without waste, though it could be more structured.
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 one simple parameter and no output schema, the description should provide more context about the output format or scope. It lists some components but does not fully characterize what the tool returns, leaving the agent guessing for comprehensive use.
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%, and the parameter description in schema is clear ('Always pass it explicitly'). The tool description adds no additional meaning beyond the schema, which is acceptable for high coverage but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists what the harness holds but does not specify a clear verb like 'get' or 'read'. It vaguely indicates a query operation, but the purpose is not sharp. Among siblings, it stands out by mentioning 'entry counts, design rules, pending changes, open questions', providing some differentiation.
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 on when to use this tool versus siblings like harness_list_pending (which might list pending changes) or harness_get_spec. No explicit use cases or exclusions are mentioned.
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?
With no annotations, the description carries full behavioral disclosure burden. It mentions 'read or update' implying mutation but provides no details on side effects, idempotency, or safety characteristics. The description does not add behavioral context beyond the basic verb-resource pairing.
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 a single sentence efficiently conveying the core purpose. It could benefit from slightly more structure but achieves conciseness without unnecessary words.
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 the tool updates a configuration file (potential side effects), has nested parameters, and no output schema, the description lacks completeness. It does not explain return values, error cases, or how to properly use the tool beyond a minimal statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 25% (only project_path described). The description mentions 'provider, model, api_key' and 'render preferences' but does not explain the meaning or relationships of these parameters, nor does it cover the design_mcp parameter at all. This is insufficient compensation for the low schema coverage.
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 the tool reads or updates /harness/config.json, specifying it configures the model for universal mode and render preferences. It uses specific verbs and resource, distinguishing it from sibling tools like harness_status or harness_get_spec.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusion criteria. It only states what the tool does without context for appropriate invocation.
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 must fully disclose behavioral traits. It only states the output (diffs, badge) but does not mention whether the tool is read-only, requires authentication, or has any side effects. This is insufficient for informed selection.
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?
Single sentence that is efficient and front-loaded. No wasted words; immediately conveys core functionality.
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 the tool's simplicity and absence of output schema, the description provides a basic understanding (pending changes, diffs, badge). However, it omits parameter semantics (status filtering) and does not indicate whether the output is a list or count alone. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only project_path documented). Description adds no meaning beyond the schema: it does not explain the status parameter or how to use it. Agent cannot infer that status filters the list (e.g., pending vs approved).
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?
Description states the tool lists pending changes with diffs and a count badge, clearly indicating the resource (pending changes) and what is produced. However, it lacks an explicit verb like 'list' but it's implied. Differentiates from siblings by focusing on pending changes, which is not covered by other harness_* 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 guidance on when to use this tool versus alternatives (e.g., harness_status, harness_verify). Description does not specify context, prerequisites, or exclusions, leaving the agent to infer usage.
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 key behavior: the change is not applied and waits in pending_changes with a diff. However, with no annotations, more detail would be beneficial, such as what happens on conflicts or auth requirements.
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, extremely concise with no wasted words. It front-loads the key behavior.
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 12 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the diff format, the effect of different ops, or how this tool fits with siblings for a complete workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about parameters beyond the input schema. Schema coverage is 50%, and the description does not compensate by explaining enums, nested objects, or parameter interactions.
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 it proposes a precise change that is NOT applied but waits for human review. The tool name and description distinguish it from siblings like harness_propose_structure, though explicit differentiation could be stronger.
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 usage for human-in-the-loop changes without model involvement, but it does not specify when to use this tool over alternatives like harness_propose_structure or harness_configure. No explicit guidance on prerequisites or when not to use.
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 reveals that results land in pending changes for review, indicating the tool does not directly apply changes. However, with no annotations, it could further specify whether the operation is additive only, whether it can overwrite, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the core purpose and add a key behavioral detail. Every word earns its place with no redundancy.
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 the tool's simplicity (2 params, no output schema), the description covers the basic function and outcome. However, it lacks parameter semantics and usage context relative to siblings, which reduces completeness for an AI agent deciding between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'instruction' parameter, which is undocumented in the schema. The 'project_path' parameter is described in the schema but not in the description. With 50% schema coverage, the description fails to compensate for the missing instruction details, such as format or examples.
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 the tool generates or extends project structure (modules, entities, screens, flows) from an instruction, which is a specific verb and resource. It distinguishes well from siblings like harness_propose_change (which modifies specific files) and harness_get_spec (retrieves specs).
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 provides no guidance on when to use this tool versus alternatives such as harness_propose_change or harness_configure. It does not mention prerequisites or scenarios where this tool is appropriate.
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?
Discloses that the harness is never redrawn and operation is on-demand, but with no annotations, critically fails to specify read-only behavior, return format, side effects, or auth requirements. A comparison tool should clarify whether it's safe to invoke repeatedly.
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 sentences, zero wasted words. Front-loaded with key constraint ('On demand only') and purpose. Perfectly concise.
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 single-parameter verification tool, the description adequately covers purpose and a key behavioral nuance. Given no output schema and no annotations, additional details on return values or error handling would improve completeness, but the tool's simplicity keeps the gap small.
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% with a clear description of project_path. Description adds no further parameter information beyond the schema, so baseline score of 3 applies.
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?
Clearly states the tool compares real code against harness and reports divergences. Specifies 'on demand only' and contrasts with 'harness is never redrawn from code', distinguishing it from sibling tools like harness_sync_design_system or harness_reverse.
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?
Implies usage for detecting drift ('safety net for when the agent drifted') but provides no explicit when-not-to-use or naming of alternative tools. The sibling list is extensive but not leveraged for guidance.
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 states 'Read' implying a read-only operation with no side effects, which is sufficient. However, it does not elaborate on the output structure or any limitations, relying on the input schema for parameter details.
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 extremely concise with only two sentences, no wasted words, and immediately states the action. It is front-loaded and efficient.
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 the lack of an output schema, the description could be more complete by hinting at the return value (e.g., the specification content). It adequately covers when to use but leaves the exact output somewhat implied by the tool name and context.
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%, with clear descriptions for all parameters (type, format, project_path). The description adds no additional meaning beyond what the schema provides. Baseline score of 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 clearly states 'Read the harness' and emphasizes its role as the constitution from which the agent must not depart, which is a specific verb+resource. This distinguishes it from sibling tools like harness_status or harness_verify, which have different purposes.
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 instructs 'Call it before writing code; the constitution belongs in every turn,' providing clear context on when to use. However, it does not mention when not to use or compare with alternatives, but given the sibling tools, no alternative exists for reading the spec.
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?
No annotations exist, so the description bears full burden. It discloses key behaviors: creates harness from existing code, marks assumptions with questions, and prioritizes code over docs. Could mention file creation side effects, but overall sufficient.
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 sentences: first states purpose, second gives guidelines. No redundancy, every word earns its place. Front-loaded with action.
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?
Covers purpose, usage, behavior, and parameter tips. Lacks explicit mention of output/return value (no output schema, but description could state what the tool produces). For a medium-complexity tool, this is a noticeable gap.
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 coverage is 100% (baseline 3). Description adds value by explaining when to pass 'analysis' ('Optional richer analysis... to use instead of a shallow scan') and clarifies 'hint' as 'Extra context... anything the code cannot contain', going beyond schema descriptions.
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 specific verbs 'Create /harness and reverse-assemble' and resource 'harness' with qualifier 'from EXISTING code'. It clearly distinguishes from sibling tools like harness_propose_structure (proposing new structure) and harness_verify (checking).
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 use context: 'Code is the evidence', when to pass 'analysis', and what happens with inferred intent. It implies when not to use (when no existing code), but doesn't explicitly name alternatives, though siblings suggest them.
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?
The description details the actions taken (connect, pull, store, queue), providing reasonable transparency. However, it does not discuss side effects (e.g., overwrite behavior) or error conditions, which would be beneficial given no annotations.
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: first captures core functionality, second provides usage context. No redundant information; extremely concise.
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?
The description covers the main workflow and usage context adequately. It could mention output or follow-up, but the sibling list partially fills that gap. Reasonably complete for a sync tool.
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 input schema covers 100% of parameters with clear descriptions. The tool description does not add additional meaning beyond the schema, meeting 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 clearly states the tool's action (sync design system from external server), describes the mechanism (connects to Design MCP server, pulls tokens and rules, stores tokens, queues rules), and distinguishes from a sibling tool (harness_set_design_tokens). It is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly provides when-to-use and when-not-to-use guidance, naming the alternative harness_set_design_tokens. This helps the agent choose correctly.
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:

[![harness-mcp MCP server](https://glama.ai/mcp/servers/mykolariabokon/harness-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mykolariabokon/harness-mcp)

Score Badge

Copy to your README.md:

[![harness-mcp MCP server](https://glama.ai/mcp/servers/mykolariabokon/harness-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mykolariabokon/harness-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/mykolariabokon/harness-mcp'

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