Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AE Test Bridge MCP Start a mock bridge, queue a response for 'app.project.activeItem.name', and show received requests."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A fake Adobe After Effects bridge listener — same wire protocol as the real thing — for testing bridge client code without needing real After Effects running. Also exposed as an MCP server, so an AI agent can spin one up, script its responses, and inspect what a client under test sent it, entirely conversationally.
Part of a small set of related repos:
AE_Bridge_MCP — the real MCP server for live After Effects introspection/eval.
AE_Eval — the same capability as a plain terminal CLI.
IPC_Client — the
general-purpose transport client this repo's MockAEBridge speaks the
same protocol as (this repo re-implements the send/recv framing
inline rather than depending on that package, to stay a standalone,
zero-dependency install).
This repo exists because none of the three above had anything to test against other than mocking the transport itself — a real fake server closes that gap and lets a client under test exercise its actual socket code, not a stand-in for it.
ae_test_bridge_mcp/mock_server.py — MockAEBridge: a real TCP
server. Register canned responses with .when(match, response)
(matched by a substring in the request's script field, or an
arbitrary predicate), a .default(response) fallback for anything
unmatched, then point a real client at bridge.host/bridge.port.
Every request it receives is recorded in bridge.received_requests
for assertions.
ae_test_bridge_mcp/server.py — an MCP server wrapping one
MockAEBridge instance behind 7 tools (below), for an AI agent to
drive directly instead of writing Python.
It cannot actually evaluate the ExtendScript in a request's script
field — there's no JS engine here, it's a test double. You tell it what
to say back; it doesn't compute anything.
Related MCP server: SpyNet
Tool | What it does |
| Start listening (optional |
| Stop the running mock bridge. |
| Register a canned response for requests whose |
| Set the fallback response for anything no |
| Return every request received so far, in order. |
| Clear the recorded history without stopping the bridge or its rules. |
| Remove all |
pip install -e .
# or, for running tests too:
pip install -e ".[dev]"Zero runtime dependencies.
from ae_test_bridge_mcp import MockAEBridge
with MockAEBridge() as bridge:
bridge.when("app.project.activeItem.name", {"status": "OK", "result": "Hero Comp"})
bridge.default({"status": "OK", "result": None})
# Point whatever you're testing at 127.0.0.1:bridge.port instead of
# the real After Effects listener's fixed port (45445) --
# e.g. ipc_client.execute_job(job, port=bridge.port).
assert bridge.received_requests[-1]["script"] == "..."Responses can also be a one-argument callable (request_dict) -> dict
for dynamic or stateful behavior (an incrementing counter, echoing part
of the request back, simulating a value that changes across calls):
bridge.when("echo", lambda req: {"status": "OK", "result": req["script"]})Rules are checked in registration order — the first match wins.
{
"mcpServers": {
"ae-test-bridge": {
"command": "python3",
"args": ["-m", "ae_test_bridge_mcp"]
}
}
}A typical agent-driven session: call start_mock_bridge, note the
returned port, tell the client under test to connect to that port
instead of the real one, call queue_response for the scenarios you
want to exercise, run the client, then call get_received_requests to
confirm it sent what you expected.
Hardened tool dispatch. Every MCP tool call is wrapped so a bad
argument (wrong type, missing field) returns a normal isError: true
result — it can never raise out of handle_call_tool and kill the
whole persistent stdio server process. This was a real bug found in a
sibling repo during a review pass; fixed here from the start.
One bridge at a time, by design. The MCP tool surface manages a
single module-level MockAEBridge instance — start_mock_bridge
fails loudly if one is already running rather than silently leaking
the old one. For multiple concurrent fake bridges in the same process,
use the MockAEBridge class directly instead of the MCP tools.
Each accepted connection runs on its own thread, so a slow or stuck client doesn't block other connections. Rule/state mutation is lock-protected so registering rules from the main thread while a request is mid-dispatch is safe.
A raising response callable never kills the connection silently.
If a .when()/.default() callable raises, the client gets back a
clean {"status": "ERROR", "error": "... raised ValueError: ..."}
instead of the socket just closing with zero bytes.
A registered response that isn't JSON-serializable (a set, an
arbitrary object) gets the same treatment — a clean error naming the
problem, not a silent close.
Declared message length is capped (max_size, default 10 MiB,
same class of protection as IPC_Client's own max_size — built
independently here since this repo deliberately has zero
dependencies) so a peer claiming a huge body can't make the server
block trying to read it.
stop() force-closes in-flight connections rather than waiting
out their own read timeout, so tearing down a bridge mid-test doesn't
leave a stray thread appending to received_requests after the
caller believes it's gone.
pip install -e ".[dev]"
pytest tests/Tests use real sockets throughout — no mocking of the socket module —
covering rule matching/ordering, dynamic responses, request recording,
malformed input on both the raw-socket layer and the MCP tool-argument
layer, and the full MCP JSON-RPC stdio loop.
v1.1.0 — Hardening pass from a first-round review: a raising
response/default callable now returns a clean ERROR result instead
of silently dropping the connection; a non-JSON-serializable response
gets the same treatment instead of closing with zero bytes; incoming
messages are capped at max_size (default 10 MiB) so a peer can't
make the server block trying to read an oversized declared length;
stop() now force-closes any in-flight connections and joins their
threads instead of waiting out their own read timeout. Also added the
clear_rules tool/method for symmetry with clear_received_requests.
v1.0.0 — Initial extraction, as a mock-bridge test double inspired
by (but not a direct port of) Dimension's own test_ae_bridge_mcp.py
patterns.
MIT — see LICENSE.
Clear the recorded request history without stopping the bridge or its response rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden 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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Remove all queue_response rules without stopping the bridge or clearing received-request history. The default response (if set) is unaffected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Return every request the mock bridge has received so far, in order -- for asserting what a client under test actually sent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Register a canned response: any incoming request whose script field contains match gets response back. Rules are checked in the order they were registered; the first match wins.
| Name | Required | Description | Default |
|---|---|---|---|
| match | Yes | Substring to look for in the request's `script` field. | |
| response | Yes | The JSON object to send back when this rule matches. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Set the response returned when no queue_response rule matches an incoming request.
| Name | Required | Description | Default |
|---|---|---|---|
| response | Yes | The JSON object to send back for any unmatched request. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Start a fake After Effects bridge listener speaking the real wire protocol, for testing bridge client code without real After Effects. Fails if one is already running.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | TCP port to listen on. 0 (default) picks a free port automatically -- check the response for the actual port. |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Stop the currently running mock bridge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0clear_received_requestsclear_rulesget_received_requestsqueue_responseset_default_responsestart_mock_bridgestop_mock_bridgeScored across 7 tools
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.
All 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.
Seven 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.
The 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for e-mail testing: create disposable inboxes, wait for delivery, and extract e-mail content or links - all from your AI agent or test automation workflow. Get a free API key on https://app.zyntra.app/
AI-callable tools for API mocking, testing, monitoring, security, and automation.
AI-native mock API server with MCP. Create REST/SOAP mocks from Claude, Cursor, or Windsurf.
Build, validate, and manage API simulations in WireMock Cloud from MCP-compatible AI agents.