Given a rack (a set of module ids the user owns), rank the modules NOT in the rack by how many rack members they pair with. The set-level companion to find_compatible_with: where that answers "what pairs with module X?", this answers "given my whole rack, what single module should I add — the one...
Risk signalsBulk/mass operation — affects multiple targets
Part of the Eurorack server.
Free to start. No card required.
AI agents invoke reachable_pairings to trigger processes or run actions in Eurorack. Execute operations can have side effects beyond the immediate call -- triggering builds, sending notifications, or starting workflows. Rate limits and argument validation are essential to prevent runaway execution.
reachable_pairings can trigger processes with real-world consequences. An uncontrolled agent might start dozens of builds, send mass notifications, or kick off expensive compute jobs. PolicyLayer enforces rate limits and validates arguments to keep execution within safe bounds.
Execute tools trigger processes. Rate-limit and validate arguments to prevent unintended side effects.
{
"version": "1",
"default": "deny",
"tools": {
"reachable_pairings": {
"limits": [
{
"counter": "reachable_pairings_rate",
"window": "minute",
"max": 10,
"scope": "grant"
}
]
}
}
}See the full Eurorack policy for all 17 tools.
These attack patterns abuse exactly the kind of access reachable_pairings gives an agent. Each links to the full case and the policy that stops it:
Other execute tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.
Given a rack (a set of module ids the user owns), rank the modules NOT in the rack by how many rack members they pair with. The set-level companion to find_compatible_with: where that answers "what pairs with module X?", this answers "given my whole rack, what single module should I add — the one that pairs with the most of what I already have?". The ranking signal is pair_count — the number of DISTINCT rack members a candidate pairs with. A module that modulates five of your modules ranks above one that modulates one. This aggregate is the point: you can't get it from per-module find_compatible_with calls without tallying distinct members by hand. Use this for: - "What should I add to a rack with <modules>?" / "what fills out this system?" - "Given these modules, what pairs well with the most of them?" - Inspecting a rack's own internal pairing structure (the internal edges). Combination edges only. Ranking uses the seven patch-time relationships (clock-source-for, cv-source-for, modulator-for, audio-source-for, quantizer-for, trigger-source-for, envelope-target-for) — the "A and B work together in a patch" kinds. The substitution/catalog kinds (alternative-to, replaces, expander-for) are deliberately excluded: a pairing recommender shouldn't suggest replacing your modules with each other. For "what's an alternative to X?" use find_compatible_with. Args: - rack (string[], required): module ids, e.g. ["make-noise/maths", "mutable-instruments/plaits"]. Ids that match no module are returned in unknown_ids (and in unresolved with did-you-mean suggestions) rather than failing the call. Surface those rather than proceeding on a partial rack: the server is stateless about your rack — it keeps no memory of it between calls, so pass the COMPLETE current set every call. Max 64. - relationship (string, optional): restrict ranking to one combination kind above. Omit to consider all seven. - limit (number): default 25, max 100. Returns: { "rack": [{ id, name }], // the rack members that resolved "unknown_ids": [string], // rack ids that matched no module "internal": [{ from_module_id, to_module_id, relationship, source_id }], // edges within the rack "candidates": [{ id, name, manufacturer, pair_count, "pairings": [{ rack_member, relationship, direction, source_id }] // why it pairs, per member }] } direction on each pairing is relative to the rack member: 'outbound' = the candidate is the role-bearer (it relationships the member, e.g. the candidate is a modulator-for the member); 'inbound' = the member is the role-bearer. Coverage caveat: rankings are only as dense as module_relationships. A thin or empty result means the corpus hasn't recorded those edges yet, not that no good pairing exists — call report_gap if you expected matches.. It is categorised as a Execute tool in the Eurorack MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
Register the Eurorack MCP server in PolicyLayer and add a rule for reachable_pairings: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Eurorack. Nothing to install.
reachable_pairings is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the reachable_pairings rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for reachable_pairings. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
reachable_pairings is provided by the Eurorack MCP server (https://eurorackref.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 17 Eurorack tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.