AE Test Bridge MCP
Server Quality Checklist
Latest release: v1.1.1
- Disambiguation5/5
Each tool has a clearly distinct role: lifecycle management (start/stop), response configuration (queue vs default), and request inspection/reset. The relationship between queue_response and set_default_response is well-defined, so there is no real ambiguity.
Naming Consistency5/5All tools follow a consistent snake_case verb_noun pattern: start_, stop_, queue_, set_, get_, clear_. The naming style is uniform and predictable across the entire set.
Tool Count5/5Seven tools is well-scoped for a mock bridge server. Each tool covers a necessary capability—lifecycle, response control, request inspection, and state reset—without redundancy or bloat.
Completeness4/5The surface covers the full testing workflow: start/stop the bridge, configure responses, inspect received requests, and reset state. Minor extras like checking bridge status or removing individual rules are absent but not critical to the core purpose.
Average 4.1/5 across 7 of 7 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on
- 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.jsonto 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 of behavioral disclosure. It does not describe the effects of stopping the bridge (e.g., does it clear queued responses? What happens to received requests?), nor does it mention error handling if no bridge is running. For a state-changing tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no waste, front-loading the action. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple stop action with zero parameters, the description is minimal but lacks essential context such as idempotency, side effects, and how it interacts with sibling tools like start_mock_bridge. The absence of annotations heightens the need for behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters)Skip meaning no parameters to explain, so a baseline of 4 is appropriate. The description adds no parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Stop' with the resource 'mock bridge', making the action clear. It does not explicitly name its sibling 'start_mock_bridge', but the inverse relationship is obvious from the name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool instead of others. There is no mention of prerequisites (e.g., does a bridge need to be running?) or what happens if none is running. It simply states the action without context.
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 to rely on, the description provides meaningful behavioral detail: matching is substring-based, rules are evaluated in registration order, and the first match wins. It does not mention lifecycle concerns like whether registering overwrites an existing rule or what happens when no rule matches, but the core side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences pack the essential behavior: registration, matching semantics, and rule ordering. The most important detail (first match wins) is placed at the end, but the entire description is short enough that nothing is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter registration tool, the description covers the necessary operational semantics: how matching works and how multiple rules are reconciled via ordering. It does not explain what happens when no rule matches or how rules are cleared, but those concerns are plausibly handled by sibling tools and are not required to invoke this one correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters completely, so the description does not need to repeat their meanings. The description adds the key semantic that `match` is searched within the request's `script` field OG `response` is the sent payload, which lightly reinforces the schema without significantly expanding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Register a canned response') and clearly defines what the rule does: any request whose `script` field contains `match` receives `response`. It stops short of explicitly contrasting itself with sibling tools like set_default_response, which would remove any ambiguity, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling tools, such as set_default_response or clear_rules. The description explains the mechanic but not the context that would help an agent decide between registration-based matching and a default fallback.
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 exist, so the description carries the full disclosure burden. It states the core behavior (sets a fallback response for unmatched requests) but does not disclose whether repeated calls overwrite an existing default, whether the default persists across requests, or how to unset/reset it. For a mutation tool this is a meaningful but not critical 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that leads with the action ('Set the response returned') and then states the trigger condition. No filler or redundancy; every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter setter with full schema coverage and no output schema, the description covers the essential call semantics. Missing only the overwrite/persistence behavior of repeated calls and how to clear the default, which have no dedicated sibling tool and are not otherwise documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole parameter is already fully described in the schema as 'The JSON object to send back for any unmatched request'. The description reinforces that the response parameter is the fallback payload, but adds no format, constraint, or type detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Set') plus a well-defined resource: 'the response returned when no queue_response rule matches an incoming request'. Naming queue_response by name distinguishes this fallback mechanism from the rule-matching sibling, so an agent can select it without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The condition 'when no queue_response rule matches an incoming request' gives clear context: this is the catch-all fallback, to be configured alongside queue_response rules. It names the relevant alternative and the trigger condition, though it does not explicitly state when-not-to-use this tool or instruct the agent to prefer queue_response for rule-based matching.
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 are provided, so the description carries the full burden. It discloses the key behavioral trait that the listener speaks the real wire protocol and that it fails if already running. It does not mention side effects or state changes, but for a mock start tool this is adequate coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core purpose is front-loaded, the failure condition is stated clearly, and every sentence adds value. No redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), and the description covers the essential behavior and failure mode. It does not explain the response shape, but the schema mentions checking the response for the actual port, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the port parameter already has a clear description in the schema. The main description adds no parameter-specific meaning. Baseline of 3 is appropriate because the schema does the heavy lifting and no additional guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('start a fake After Effects bridge listener'), defines its purpose ('for testing bridge client code without real After Effects'), and distinguishes it from siblings by the word 'fake'. It is immediately obvious what this tool does and how it differs from the other mock-bridge tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames when to use the tool (testing without real After Effects) and the failure condition ('fails if one is already running'), implying you should stop an existing bridge first. It does not explicitly name alternative tools like stop_mock_bridge, but the context is sufficient for an agent to infer the right selection.
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 are provided, so the description carries the full burden. It conveys the read-only, stateful nature of the tool (returns all requests accumulated 'so far', in arrival order), which lets an agent infer it has no mutation side effects. It does not describe the exact return shape, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. The action ('Return'), scope ('every request... so far, in order'), and rationale ('for asserting...') are all front-loaded and each clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, this is nearly complete: an agent can invoke it immediately and understand what it returns and why. The only gap is the absence of an output schema to specify the response format, which keeps this just short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has no properties, so the baseline of 4 applies. The description adds no parameter detail, and none is needed for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Return'), names the exact resource ('every request the mock bridge has received'), and adds scope ('so far, in order') plus a stated purpose (asserting what a client actually sent). It is clearly distinct from the mutating siblings like start_mock_bridge, queue_response, set_default_response, and clear_received_requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit context: invoke this tool when you need to assert what a client under test actually sent. It does not explicitly name alternatives or exclusions (e.g., using clear_received_requests to reset the history first), but the context is clear enough to guide correct selection.
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, the description carries the full burden of behavioral disclosure. It explicitly states the tool clears history but does not stop the bridge or response rules, which is valuable context beyond the literal action. It does not mention irreversibility or other effects, but for a simple clear operation this is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no wasted words. It front-loads the primary action ('Clear the recorded request history') and immediately follows with the critical scope qualifier ('without stopping the bridge or its response rules').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema and a clear sibling set, the description fully covers what an agent needs to know: the effect, the scope, and what it does not affect. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline for 0-parameter tools is 4, and the description correctly avoids any irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Clear the recorded request history.' It distinguishes from siblings like clear_rules by specifying it clears request history, not rules. The addition of 'without stopping the bridge' also differentiates it from stop_mock_bridge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: when you want to clear history while keeping the bridge and response rules active. It implicitly tells the agent not to use it if the goal is to stop the bridge or clear rules, though it doesn't explicitly name alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses the destructive effect (removes rules) and explicitly states what remains unaffected: the bridge, received-request history, and the default response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the main action, and every clause adds distinct information about scope or side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, mutation-only tool with no output schema, the description fully covers what is removed and what is preserved, leaving no practical ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parametersholiday, and the schema coverage is 100%, so the baseline is 4; no parameter description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Remove') with a clear resource ('all queue_response rules') and immediately distinguishes the operation from bridge lifecycle and request-history tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly describes what the tool does and does not do, helping an agent choose it over related tools, though it does not explicitly name alternative tools or list when to prefer them.
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:
Score Badge
Copy to your README.md: