This MCP server lets an AI agent inspect and control a Q-SYS audio/video system over TCP using the QRC protocol (JSON-RPC 2.0), working against either a real Q-SYS Core or Q-SYS Designer's built-in emulator.
Connect & Authenticate — Establish a connection to a Q-SYS Core or emulator (qsys_connect), with optional username/password, and disconnect when done (qsys_disconnect).
Check System Status — Retrieve engine status including platform, design name, run state, and whether you're talking to an emulator (qsys_status).
Discover Components — List all named components in the running design, filterable by name substring or type (e.g. "gain", "mixer"), with an option to return names only to save context (qsys_list_components).
Inspect Controls — Get all controls and current values for a specific component (qsys_get_component_controls), or read Named Control values (qsys_get_control), or get specific controls within a component (qsys_get_component).
Write Control Values — Set a Named Control's value with an optional ramp time (qsys_set_control), or set multiple controls within a named component in a single call, each with its own optional ramp (qsys_set_component).
Load & Save Snapshots — Store and recall design snapshots (qsys_load_snapshot, qsys_save_snapshot).
Monitor Changes via Change Groups — Create change groups to watch Named Controls or component controls for live changes, poll for only what changed since the last poll, and destroy groups when done (qsys_create_change_group, qsys_change_group_add_component, qsys_poll_change_group, qsys_change_group_remove, qsys_change_group_clear, qsys_change_group_invalidate, qsys_destroy_change_group).
Because it's an MCP server, all of the above can be driven by natural language — e.g. "bring the main gain down to −20 dB over 2 seconds" — with the AI agent selecting and chaining the appropriate tools automatically.
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., "@q-sys-mcp Set the main gain to -10 dB with a 2-second ramp."
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.
Let an AI agent inspect and control a Q-SYS audio/video system over QSC's published QRC protocol — against a real Core or Q-SYS Designer's built-in emulator.
qsys-mcp is an MCP server. It speaks QSC's QRC external-control protocol (JSON-RPC 2.0 over TCP) — the same interface third-party control systems like Crestron and AMX use — and exposes it to an LLM agent as a set of tools. Point it at a physical Q-SYS Core or at Q-SYS Designer running in Emulate mode and the agent can read meters, flip mutes, ramp gains, and watch controls for changes.
It's a pure wire-protocol client: zero QSC code, no SDK, no hardware required for development. That makes it a clean, sanctioned layer QSC ships on no platform — AI-native control — and it runs anywhere Node does.
18 tools covering connect, status, discovery, read, write (with ramps), snapshots, the full change-group lifecycle (add/poll/remove/clear/invalidate/destroy), and disconnect.
No hardware needed — develop entirely against Designer's Emulate-mode soft-core on localhost.
Cross-platform — node:net only; CI proves it on Linux, macOS, and Windows × Node 18 & 20.
Context-friendly — list/get tools take filter / names_only / type so large designs don't flood the agent's context.
Safe by default — write tools warn when they're hitting a live Core (not an emulator); a 30 s NoOp keepalive holds the socket open through QRC's 60 s idle close.
Self-healing — on a dropped socket (Core restart, leaving Emulate, a network blip) the client auto-reconnects and replays your change-group registrations, so polling resumes without re-calling qsys_connect. Opt out with reconnect: false.
Related MCP server: Home Assistant MCP Server
Run it straight from npm (no install):
npx -y q-sys-mcp # MCP server on stdioPublished on npm as
q-sys-mcp; the installed command isqsys-mcp.
Or from source:
git clone https://github.com/reowens/qsys-mcp.git
cd qsys-mcp
npm install # builds dist/ via the prepare hook
node dist/index.jsAdd it to your MCP client config (Claude Desktop, etc.):
{
"mcpServers": {
"q-sys": {
"command": "npx",
"args": ["-y", "q-sys-mcp"]
}
}
}From a local checkout instead, use "command": "node" with "args": ["/absolute/path/to/qsys-mcp/dist/index.js"].
Always call qsys_connect first (host 127.0.0.1, port 1710 for a local emulator) before any other tool.
Once connected, just ask in natural language — the agent picks the tools.
You: "Connect to my Q-SYS emulator and bring the main gain down to −20 dB over 2 seconds."
The agent runs:
qsys_connect → { host: "127.0.0.1", port: 1710 }
qsys_list_components → { type: "gain" } — finds the Levels gain block
qsys_set_component → { name: "Levels", controls: [{ name: "gain", value: -20, ramp: 2 }] }
Or, if you've exposed that fader as a Named Control in Designer:
qsys_set_control → { name: "MainGain", value: -20, ramp: 2 }To watch a control live (meters, button states), create a change group and poll it:
qsys_create_change_group → { id: "meters", controls: ["MainGain"] }
qsys_poll_change_group → { id: "meters" } // returns only what changed since the last pollTool | QRC method | Purpose |
| (socket) + | Connect to a Core/emulator |
|
| Engine status (platform, design, run state) |
|
| List named components |
|
| A component's controls + values |
|
| Get Named Control values |
|
| Get specific component control values |
|
| Set a Named Control (with optional ramp) |
|
| Set component controls (with optional ramps) |
|
| Recall a saved snapshot (with optional ramp) |
|
| Capture current settings into a snapshot |
|
| Watch Named Controls for changes |
|
| Watch a component's controls |
|
| Get changes since last poll |
|
| Stop watching specific Named Controls |
|
| Remove all controls, keep the group |
|
| Force the next poll to resend everything |
|
| Free a change group's server-side state |
| (socket) | Close the connection |
qsys_list_components and qsys_get_component_controls accept optional filter (case-insensitive name substring), names_only, and — for components — type, to trim large designs before they reach the agent's context.
Q-SYS exposes controls two ways, and the tools mirror that split:
Named Controls (qsys_get_control / qsys_set_control) reach a control only if it's been explicitly exposed — dragged into the Named Controls pane in Designer with a unique name. Flat namespace, addressed by that one name.
Component controls (qsys_get_component_controls / qsys_get_component / qsys_set_component) reach any control on a component whose parent has a Code Name with Script Access enabled — no per-control naming needed.
If qsys_get_control can't find a name, it almost always means the control hasn't been added to the Named Controls pane.
Node.js ≥ 18.
A control target on port 1710:
a real Q-SYS Core with a design loaded and in Run mode, or
Q-SYS Designer in Emulate mode — open a design and press F6 (Save to Design & Run; not F5, which deploys to a physical Core). Connect to 127.0.0.1:1710.
QRC is fully functional in Emulate mode, so you can build and test without any hardware.
Writes mutate the running/emulated system. On an emulator, nothing persists unless you save the design in Designer.
npm test # offline: QRC integration + MCP-over-mock (no hardware)
npm run smoke -- 127.0.0.1 1710 # read-only smoke against a live emulator/Core
npm run smoke:mcp -- 127.0.0.1 1710 # full MCP-over-stdio smoke against a live target
npm run smoke:write -- 127.0.0.1 1710 # live WRITE round-trip: set a gain, verify, restore
npm run smoke:named -- MainGain # live Named-Control read/set + change-group poll
npm run smoke:keepalive # idle >60s, prove the socket survives QRC's idle closenpm test needs no hardware; every smoke:* script needs a live target (a real Core, or Designer in Emulate mode, on port 1710).
CI runs npm ci && npm run build && npm run typecheck && npm test on Linux, macOS, and Windows × Node 18 & 20 (.github/workflows/ci.yml). The whole suite is hardware-free — a mock QRC server plus an in-memory MCP transport — so the full matrix runs without a Core.
WebSocket transport via @q-sys/qrwc — a convenience adapter for real Cores. Raw QRC is the primary transport today; the lib is still beta.
Real-Core validation — every test so far runs against Designer's emulator; a physical Core run is the honest trigger to graduate to 1.0.0.
Design authoring (reading/writing .qsys files) — out of scope: .qsys is a compressed .NET BinaryFormatter graph type-coupled to QSC's assemblies.
See CHANGELOG.md for release notes, or the GitHub releases page.
MIT — see LICENSE. Q-SYS and QRC are trademarks/protocols of QSC, LLC; this project is an independent client and is not affiliated with or endorsed by QSC.
Add a named component's controls to a change group so you can poll them for changes (ChangeGroup.AddComponentControl).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Change group id (any string; reused on poll) | |
| controls | Yes | Control names within the component to watch | |
| component | Yes | Component name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks disclosure of side effects, prerequisites (change group must exist), error cases, or return value. Only states the basic action and purpose.
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?
Single, front-loaded sentence with no unnecessary information. Efficiently states action and purpose.
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?
Adequate for a simple add operation but incomplete without mentioning that the change group must already exist or what happens on error. Sibling tools provide some implicit context, but description should be self-contained.
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?
Input schema covers all 3 parameters with clear descriptions. The description adds marginal context (method name, polling purpose) but does not significantly enhance understanding beyond schema.
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?
Description clearly states verb (Add), resource (component's controls), target (change group), and purpose (poll for changes). Distinct from siblings like qsys_create_change_group and qsys_poll_change_group.
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?
Implied usage context (add before polling) but no explicit when-to-use guidance or comparison to alternatives like qsys_set_control or qsys_get_component_controls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove all controls from a change group without destroying it (ChangeGroup.Clear).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Change group id |
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 clarifies that the group is not destroyed, which is key behavioral info. However, it does not disclose potential side effects, required permissions, or behavior on non-existent groups.
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 concise sentence that is front-loaded with the action. Every word adds value, with no wasted text.
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's simplicity (one parameter, no output schema), the description adequately covers the core functionality and the key nuance of preserving the group. Missing details about error handling or empty groups are minor gaps.
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 parameter 'id' has a description in the schema. The tool description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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 clearly states the action 'Remove all controls from a change group' and the resource 'change group'. It explicitly distinguishes from destroying the group by saying 'without destroying it', which differentiates it from sibling tool qsys_destroy_change_group.
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 implies usage for clearing all controls while preserving the group, but does not explicitly state when to use this tool versus alternatives like qsys_change_group_remove (which removes individual controls). No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invalidate a change group so the next poll resends every watched control, not just the changes (ChangeGroup.Invalidate). Handy after a reconnect to force a full snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Change group id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It explains that the next poll will resend all watched controls, not just changes, and that it forces a full snapshot. It does not mention potential side effects or idempotency, but is fairly transparent for a simple tool.
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 two sentences, front-loaded with the primary action and effect, and includes a practical use case. Every sentence adds value with no unnecessary words.
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's simplicity (one parameter, no output schema), the description fully covers the purpose, effect, and a typical usage scenario. It is complete and leaves no major gaps for the agent.
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 input schema has 100% coverage with the parameter description 'Change group id'. The tool description does not add any additional meaning or clarification 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool invalidates a change group so the next poll resends every watched control, not just changes. It gives a specific verb (invalidate) and resource (change group), and explicitly contrasts with normal incremental behavior, distinguishing it from sibling tools like qsys_poll_change_group.
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 a clear use case: 'Handy after a reconnect to force a full snapshot.' This tells the agent when to use it, but does not explicitly exclude other scenarios or mention alternatives like normal polling when incremental updates are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove Named Controls from a change group, leaving the group in place (ChangeGroup.Remove). Returns any unknown control names.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Change group id | |
| controls | Yes | Named Control names to stop watching |
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 that the group remains in place and that unknown control names are returned, which adds value. However, it does not mention side effects, permission requirements, or error handling beyond the return of unknown names. More detail on behavior during failure would improve transparency.
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 extremely concise: two sentences, no filler. The main action is front-loaded ('Remove Named Controls from a change group'), followed by a clarifying behavioral note. Every word serves a purpose.
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?
With two well-described parameters and no output schema, the description provides sufficient context: the action, the parameters (via schema), and the return value (unknown names). The tool's complexity is low, and the description covers all essential aspects without leaving gaps. Sibling tools are not necessary to mention for completeness here.
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 descriptions cover both parameters (id: 'Change group id', controls: 'Named Control names to stop watching'). The description adds meaning by stating that the tool returns any unknown control names, clarifying what happens when the controls parameter contains names not in the group. This goes beyond the schema's static info.
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 clearly states it removes named controls from a change group while leaving the group intact. It explicitly mentions the underlying operation (ChangeGroup.Remove) and distinguishes from siblings by focusing on removal of specific controls. The addition about returning unknown control names adds precision.
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 implies usage when you want to remove specific controls without deleting the group, but does not provide explicit guidance on when to use this tool versus alternatives like qsys_change_group_clear (removes all) or qsys_change_group_invalidate. No when-not-to-use or prerequisite info is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to a Q-SYS Core or to Q-SYS Designer running in Emulate mode (press F6 in Designer), over the QRC protocol (TCP). For a local emulator use host "127.0.0.1" and port 1710. Must be called before any other tool.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Core IP/hostname, or 127.0.0.1 for a local Designer emulator | 127.0.0.1 |
| port | No | QRC port (default 1710) | |
| user | No | Username, if the design requires authentication | |
| password | No | Password, if the design requires authentication | |
| reconnect | No | Auto-reconnect on a dropped socket (Core restart, network blip), replaying change-group registrations so polling resumes. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description covers protocol (QRC over TCP), authentication, and auto-reconnect behavior with details on replaying registrations. This is comprehensive for a connect tool.
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 two sentences long, front-loading the main purpose and adding the prerequisite in the second. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and parameters, but it does not mention what the tool returns upon success or failure. Given no output schema, this minor gap exists.
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 description adds value by explaining the rationale for default host/port values and the reconnect parameter's behavior, enhancing understanding beyond the schema.
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 clearly states the verb 'Connect' and the resource 'Q-SYS Core or Q-SYS Designer Emulator', with specific protocol details. It also distinguishes from sibling tools by noting it must be called first.
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 explicitly says 'Must be called before any other tool' and provides specific host/port examples for local emulator, giving clear context. It lacks explicit when-not-to-use instructions but is sufficient for its role as a setup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a change group (or add Named Controls to an existing one) so you can poll for changes (ChangeGroup.AddControl).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Change group id (any string; reused on poll) | |
| controls | Yes | Named Control names to watch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden but only hints at behavior (e.g., 'reused on poll'). It does not disclose side effects, required permissions, error conditions, or what happens when the ID already exists beyond the implicit extension capability.
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, front-loaded sentence that efficiently conveys the main action and intention. It contains no unnecessary words, though it could incorporate slightly more structural detail.
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 tool with two required parameters and no output schema, the description covers the essential purpose but lacks information about return values, success/failure indicators, or common use cases. It is adequate but not fully comprehensive.
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%, with both parameters already described in the schema. The description adds minimal value by rephrasing the purpose ('add Named Controls to an existing one'), which aligns with the 'controls' parameter. However, it does not compensate beyond baseline.
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 explicitly states the tool's action ('Create a change group or add Named Controls to an existing one') and its purpose ('so you can poll for changes'). It distinguishes this tool from siblings like 'qsys_destroy_change_group' and 'qsys_poll_change_group' by focusing on creation/extension.
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?
No guidance is provided on when to use this tool versus alternatives such as 'qsys_change_group_add_component'. The description does not mention prerequisites, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destroy a change group, freeing its server-side state (ChangeGroup.Destroy).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Change group id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully explain behavior. While it indicates destructiveness, it fails to disclose important traits such as idempotency, error handling, or side effects like what happens to related data or if the group is in use.
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 concise with one sentence that front-loads the action. However, it could be slightly more informative without sacrificing brevity.
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 destructive tool with no output schema, the description lacks crucial contextual details about behavior, error conditions, and prerequisites, making it insufficient for safe usage.
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 input schema has 100% coverage with a single parameter 'id' described. The tool description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
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 clearly states the tool destroys a change group, with the additional detail of freeing server-side state. It effectively distinguishes from siblings like qsys_create_change_group and qsys_poll_change_group.
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 no explicit guidance on when to use this tool vs alternatives, nor any prerequisites or conditions for use. It lacks context about proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the QRC connection to the Core/emulator. A later qsys_connect is required before other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description simply states the disconnection action. It doesn't disclose details like whether unsaved changes are lost or if the tool is idempotent, but for a simple disconnect, it's adequate.
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, front-loaded with the action, and every word is necessary. No wasted text.
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 tool with no parameters and no output schema, the description is sufficient. It covers purpose and the need for reconnection, though it could mention error handling for already disconnected state.
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?
There are zero parameters, and the schema coverage is 100%, so the description has no additional parameter burden. Baseline 4 applies.
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 clearly states the action 'Close the QRC connection' and specifies the resource 'Core/emulator', making it distinct from sibling tools like qsys_connect.
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?
It explicitly mentions that a later qsys_connect is required before using other tools, providing clear context for when to use this tool, though it could explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific control values within a named component (Component.Get).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component name | |
| controls | Yes | Control names within the component |
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. The description only states 'Get specific control values', implying a read operation, but it does not explicitly confirm non-destructiveness, authorization needs, error behavior, or return characteristics. For a read tool, the description is insufficiently 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?
The description is a single, front-loaded sentence that efficiently conveys the core action. However, it could include brief additional context like return format without harming conciseness. It is not verbose but lacks minor completeness for a top score.
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 has 2 required parameters, no output schema, and 11 sibling tools, the description is minimally complete. It states what the tool does but does not clarify the return format, page size limitations, or how it differs from similar tools like qsys_get_control. It is adequate but leaves gaps for an AI agent.
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% because both parameters ('name' and 'controls') have descriptions in the input schema. The tool description adds no additional meaning beyond what the schema already provides, meeting the baseline for a tool with high coverage. No further semantic value is contributed.
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 clearly states the verb 'Get' and the specific resource 'control values within a named component'. It uses the phrase 'Component.Get', which adds technical context and distinguishes it from sibling tools like qsys_get_component_controls (which lists control names) and qsys_get_control (which targets a single control).
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 no guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference any prerequisites, context, or exclusions. The agent must infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a named component's controls and current values (Component.GetControls). Use filter/names_only to trim large components.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component name (as returned by qsys_list_components) | |
| filter | No | Case-insensitive substring; only controls whose name contains it are returned | |
| names_only | No | Return only control names (drop values/positions) to save context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states the tool lists controls and values, implying a read operation, but does not mention permissions, rate limits, or whether the operation is destructive. Minimal behavioral context.
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 no wasted words. The first sentence states the purpose, the second gives actionable guidance. Well-structured and front-loaded.
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?
Covers basic purpose and parameter usage, but omits details like return format (list of objects?), error handling (e.g., component not found), or whether all controls are returned. For a tool with no output schema, more context is needed for complete understanding.
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 covers 100% of parameter descriptions. The description adds value by explaining why to use filter and names_only ('to trim large components'), which helps the agent decide when to apply those parameters.
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 clearly states the tool lists a named component's controls and current values, with the specific API call 'Component.GetControls'. It distinguishes from siblings like qsys_get_control (single control) and qsys_list_components (list all components).
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?
Provides a usage tip for the filter and names_only parameters to handle large components, but lacks explicit guidance on when to prefer this tool over alternatives (e.g., qsys_get_control for a single control) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current values of one or more Named Controls (Control.Get).
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Named Control names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, error handling, or side effects. For a get operation, this is minimal but still lacks detail.
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 sentence, no redundant words. However, it could include more information without sacrificing conciseness.
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 getter with one parameter and no output schema, the description is adequate but lacks mention of return format, potential errors, or behavior for missing controls.
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% with a description for the 'names' parameter. The tool description adds little beyond the schema, reiterating 'one or more' and 'current values'.
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 clearly states 'Get the current values of one or more Named Controls' with a specific verb and resource. It distinguishes from siblings like qsys_set_control.
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 implies usage for retrieving current values but offers no explicit guidance on when to use this tool versus alternatives like qsys_get_component or qsys_get_component_controls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List named components in the running/emulated design, with type and properties (Component.GetComponents). On large designs use filter/type/names_only to trim the response.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Case-insensitive substring on component type (e.g. "gain", "mixer") | |
| filter | No | Case-insensitive substring; only components whose name contains it are returned | |
| names_only | No | Return only name + type per component (drop properties) to save context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions the underlying function (Component.GetComponents) and implies a read-only operation, but does not explicitly state it is non-destructive, disclose permissions requirements, or describe response size limits beyond the filter hint.
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 consists of two concise sentences. The first states the purpose, and the second provides actionable guidance. Every sentence adds value without redundancy.
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 lack of an output schema, the description explains what is returned (components with type and properties) and how to trim responses. It does not cover pagination, but the parameter guidance partially compensates. Overall, it is reasonably complete for a list tool.
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 input schema has 100% description coverage, so the baseline is 3. The description adds only a general usage tip for the parameters ('use filter/type/names_only'), which does not significantly augment the schema's parameter descriptions.
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 clearly states the action ('List named components') and the resource ('running/emulated design'), adding details about type and properties. The verb+resource is specific and distinguishes from siblings like qsys_get_component, which targets a single component.
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 implicit guidance ('On large designs use filter/type/names_only'), but does not explicitly state when to use this tool versus siblings like qsys_get_component or qsys_status. No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall control settings from a saved snapshot bank/number, optionally ramped over seconds (Snapshot.Load). This MUTATES the running/emulated system.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | Yes | Snapshot bank name, as named in Q-SYS Designer | |
| ramp | No | Ramp time in seconds (optional) | |
| number | Yes | Snapshot number within the bank (1-based) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions mutation ('This MUTATES the running/emulated system'), but lacks details on side effects, permissions required, or behavior under error conditions (e.g., invalid bank/number).
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 consists of two concise sentences with no extraneous information. Essential details are front-loaded, and every word adds value.
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 has three parameters, no output schema, and no annotations, the description is adequate but not thorough. It explains the core function and mutation behavior, but omits details like return values, error handling, or the effect on the current system state beyond mutation.
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 input schema has 100% coverage for parameters, so the baseline is 3. The description adds minimal extra meaning: it notes ramp is optional and timed in seconds, which matches the schema. No additional context for bank or number beyond the schema descriptions.
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 clearly specifies the action ('Recall control settings') and the resource ('saved snapshot bank/number'), with optional ramp. It distinguishes from the sibling 'qsys_save_snapshot' by mentioning this is a load operation.
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?
No explicit guidance on when to use this tool over alternatives. While it notes the tool mutates the system, it does not compare to other mutation tools like qsys_set_control or provide criteria for when to recall a snapshot instead of direct control changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a change group; returns the controls that changed since the last poll (ChangeGroup.Poll).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Change group id |
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 the tool returns changed controls since last poll, implying a non-destructive read. However, it does not disclose error handling or any potential side effects.
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 sentence with no unnecessary words. It is front-loaded and efficient, earning 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?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is mostly complete. It explains the return value. Minor gap: no mention of error conditions or prerequisites.
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 single parameter 'id' is described in the schema as 'Change group id'. The description adds no additional semantic meaning beyond the schema, which already fully covers it (100% coverage).
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 clearly states the tool polls a change group and returns changed controls. It distinguishes from siblings like create/destroy/connect by specifying polling behavior.
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 implies when to use (to get updates from a change group) but does not explicitly mention alternatives or when not to use. The context is clear enough but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the current control settings into a snapshot bank/number (Snapshot.Save). This OVERWRITES the stored snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | Yes | Snapshot bank name, as named in Q-SYS Designer | |
| number | Yes | Snapshot number within the bank (1-based) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral trait: it overwrites the stored snapshot. Without annotations, this carries the full burden, but lacks details on side effects or authentication.
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 conveying purpose and critical overwrite warning, no fluff, action front-loaded.
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 tool with two straightforward parameters and no output schema, the description is fully adequate.
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 already provides 100% coverage with descriptions for both parameters. Description adds no new meaning beyond restating 'bank/number'.
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?
Clearly states the verb 'Capture' and resource 'current control settings into a snapshot bank/number', differentiates from sibling qsys_load_snapshot by explicitly mentioning 'Save' and overwriting.
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?
Implicitly clear usage context through sibling names (e.g., qsys_load_snapshot for loading), but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set one or more control values within a named component, each optionally ramped (Component.Set). This MUTATES the running/emulated system.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component name | |
| controls | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states mutation (MUTATES) and mentions optional ramping, which are helpful behavioral cues. However, with no annotations, it lacks details on idempotency, error behavior, or system state implications.
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 succinct with two sentences: one for purpose and one for behavioral note. No redundant phrases.
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 mutation tool with no output schema and multiple siblings, the description covers the main operation and mutation. However, it lacks context on required component existence, error handling, and return value.
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 description adds meaning by explaining ramp as optional and that controls is an array of one or more control-value pairs. However, with 50% schema coverage, it does not fully describe the properties within controls (e.g., what 'name' refers to within the component).
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 clearly states the verb 'set' and resource 'control values within a named component'. It mentions optional ramping and explicitly calls out that it mutates the system, which distinguishes it from read-only siblings like qsys_get_component.
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 implies that this tool is for setting one or more controls (vs. single control via qsys_set_control), but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a Named Control value, optionally ramped over a number of seconds (Control.Set). This MUTATES the running/emulated system.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Named Control name | |
| ramp | No | Ramp time in seconds (optional) | |
| value | Yes | New value (number, string, or boolean) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'This MUTATES the running/emulated system', which is good. However, lacks details on side effects, value validation, or what happens if control doesn't exist. No annotations provided to supplement.
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: first states purpose, second warns mutation. No wasted words.
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?
No output schema or annotations. For a mutation tool, more detail on reversibility, constraints, or return behavior would be helpful. But it's adequate for a simple set operation.
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 covers all parameters (100%). Description adds ramp context ('optionally ramped over a number of seconds') beyond schema. Name and value are straightforward.
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 clearly states the verb 'Set' and the resource 'Named Control value', specifying optional ramp. It distinguishes from siblings like qsys_get_control (read) and qsys_set_component (component-level), but could be more explicit about the scope of 'Named Control'.
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?
No guidance on when to use this tool versus alternatives (e.g., qsys_set_component). No prerequisites, context for ramp usage, or error handling mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Q-SYS engine status: platform, design name, run state, emulator flag.
| 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 must fully disclose behavior. It indicates a read operation ('Get') but does not mention whether a prior connection is required, side effects, or if it is safe to call repeatedly.
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, concise sentence that front-loads the purpose and enumerates key fields. No unnecessary words.
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 no output schema and no annotations, the description is adequate for a simple status check but lacks behavioral context such as the need for a connection or the format of the returned data.
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?
There are zero parameters, so schema coverage is 100%. The description adds value by listing the returned fields, providing context beyond the empty schema.
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 clearly states the tool's function: 'Get the Q-SYS engine status' and lists specific fields (platform, design name, run state, emulator flag). It distinguishes from sibling tools which focus on connections, components, and controls.
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 implies usage for checking engine status but does not explicitly state when to use it versus alternatives like qsys_connect or qsys_list_components. No exclusions or prerequisites are mentioned.
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. Dates show when Glama detected each change.
v0.2.0qsys_change_group_clearqsys_change_group_invalidateqsys_change_group_removeqsys_connect1 field changedInput schema / properties / reconnectAdded value: +{
+ "default": true,
+ "description": "Auto-reconnect on a dropped socket (Core restart, network blip), replaying change-group registrations so polling resumes. Default true.",
+ "type": "boolean"
+}qsys_load_snapshotqsys_save_snapshotv0.1.1qsys_change_group_add_componentqsys_connectqsys_create_change_groupqsys_destroy_change_groupqsys_disconnectqsys_get_componentqsys_get_component_controlsqsys_get_controlqsys_list_componentsqsys_poll_change_groupqsys_set_componentqsys_set_controlqsys_statusEach tool targets a distinct operation or resource: connection, component/control queries, change group lifecycle, snapshot management, and status. There is no overlap; descriptions clearly differentiate purposes.
All tools follow the pattern qsys_<verb>_<noun> with consistent verb usage across the set. The naming is uniform and predictable.
With 18 tools, the set is slightly above the typical 3-15 range but well-justified by the domain's complexity (connection, change groups, components, snapshots). Each tool serves a clear purpose.
The tools cover connection lifecycle, read/write access to controls and components, change group management, and snapshot load/save. Minor gaps like listing existing change groups are absent but not critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Give your AI agents the tools to build, manage, and run automation workflows.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/reowens/qsys-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
