daqmx-mcp

by BrianDavidCouch

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct resource or action: device discovery, server status, channel listing, self-test, analog input, digital input, recording, and error explanation. The two analog voltage tools are differentiated by output (in-memory statistics vs. file creation), so no agent confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_devices, get_device_details, read_digital_inputs). Even compound verbs like self_test_device and record_analog_voltage adhere to the same pattern, making the API predictable.
Tool Count5/5
With 9 tools, the server is well-scoped for a DAQmx interface, covering device management, input operations, recording, and diagnostics. The count is neither sparse nor bloated, and each tool earns its place.
Completeness4/5
Core workflows are covered: device discovery, channel enumeration, analog/digital input, recording to file, self-test, and error handling. However, analog/digital output and continuous acquisition are absent, which may be intentional for safety but represents a notable gap for a DAQmx server.
Average 3.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the 'allowed device' constraint, indicating only certain devices are valid. However, it doesn't disclose behavior like error handling or what 'capabilities' means beyond a generic term.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It front-loads the key verb and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and an output schema, so return values are covered. However, the description lacks context on how to identify an 'allowed device' (e.g., via list_devices) and what kind of capabilities are returned, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'device' parameter with no description (coverage 0%). The description adds 'one explicit allowed device', giving some context that the device must be from an allowed set, but it doesn't specify the format, source (e.g., list_devices output), or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get read-only capabilities' for a device. It clearly distinguishes from siblings like list_devices (which enumerates devices) and get_server_status (server-level info). The phrase 'one explicit allowed device' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives. It implies the device must already be known ('explicit allowed device') but gives no guidance on obtaining that device list or excluding other operations. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the finite/bounded transaction nature and the return type (statistics + preview), which are useful, but does not discuss permissions, error behavior, or side effects beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and concisely states the scope and return.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, an output schema, and annotations, but the description is minimal. It lacks usage guidance, parameter explanations, and any context about measurement setup, making it under-specified for a tool of this complexity despite the output schema covering return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention or explain any of the 10 parameters. With schema description coverage at 0%, the burden is on the description to compensate, but it only provides high-level context about the transaction type, leaving parameter semantics (e.g., sample_count vs duration_seconds, trigger_source) unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs one finite analog-voltage input transaction and returns statistics plus a preview. It distinguishes from sibling record_analog_voltage by emphasizing the finite/bounded nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a single bounded acquisition but does not explicitly compare to alternatives like record_analog_voltage or state when not to use it. No when-to-use or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the primary side effect (creating a new file) and specifies the approved directory constraint, adding context beyond the annotations. Annotations mark readOnlyHint=false, consistent with this behavior. However, it does not mention what happens if the file already exists, whether the tool blocks, or any permission/overwrite behavior, which would increase transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core action and output. However, it is under-specified for the tool's complexity, but that is a completeness issue, not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no schema descriptions, and high complexity, the one-sentence description is far from complete. It does not explain trigger behavior, volt range, sample count vs. duration, or terminal configuration. The presence of an output schema (not shown) does not compensate for the missing parameter semantics and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It only indirectly references 'format' (TDMS/CSV) and 'filename' (approved directory), leaving 10 other parameters (trigger, voltage limits, terminal configuration, sample count, etc.) unexplained. The description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: 'Perform one finite analog input and create a new TDMS or CSV file inside the approved directory.' It specifies the action (record finite analog input) and the resource (new TDMS/CSV file), distinguishing it from the sibling acquire_analog_voltage which likely does not create a file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context: one-shot recording to a file in an approved directory, but it does not explicitly state when to choose this tool over alternatives like acquire_analog_voltage. The 'one finite' and 'new file' hints provide some guidance, but there are no explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already indicate readOnly=true and destructiveHint=false, the description adds valuable behavioral context: the test is 'brief' and it intentionally does not establish electrical safety. This goes beyond what the annotations provide and helps the agent set proper expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It conveys both the action and a critical caveat, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and an output schema. The description covers the core action and a safety caveat, which is adequate for basic selection. It does not detail prerequisites or result interpretation, but given the output schema's existence, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'device' parameter's format, allowed values, or meaning beyond the tool's name. The only compensation is that the word 'device' appears in the description, but this is insufficient for a low-coverage situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and the resource ('NI-DAQmx's brief device self-test'), making the purpose explicit. It does not explicitly differentiate from sibling tools, but the self-test action is distinct enough that the score is 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for running a quick device self-test and includes a caveat that it does not establish electrical safety, which hints at a limitation. However, it lacks explicit guidance on when to use this tool versus alternatives like get_device_details, so it does not fully meet the 'clear context, no exclusions' criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about 'allowed' channels and per-device scoping, but it does not disclose behavior for invalid device inputs or what happens when no channels match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'list', and contains no filler words. It efficiently conveys the core functionality and the optional filter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema is present, so the description does not need to detail return values. It adequately explains the operation, scoping to one device, and the channel type filter, though it could mention prerequisite steps like confirming the device exists or is accessible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), and the description partially compensates by mapping 'analog-input and/or digital-input' to channel_type and 'one device' to device. However, it does not explicitly state that channel_type is optional or that omitting it returns both types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and resource 'physical channels' for 'one device', and mentions the optional filter types ('analog-input and/or digital-input'). This clearly distinguishes it from sibling tools such as list_devices and get_device_details, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it does not explicitly state when to use it versus alternatives or mention prerequisites. For instance, it does not suggest first calling list_devices to obtain a device ID, nor does it exclude use when the device is not connected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, so the description adds value by clarifying the timing mode ('software-timed') and the single-sample limitation. This gives an agent a clear behavioral expectation beyond the safety annotation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and includes key specifics (software-timed, one sample, digital-input lines). Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two required parameters and an output schema, the description adequately covers the essential behavior. It does not detail line formats or error conditions, but the existence of sibling tools like list_physical_channels may provide additional context, and the scope is narrow enough to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description partially compensates by explaining that 'lines' are explicit digital-input lines, but 'device' is left to its name. It provides some meaning beyond the bare parameter names but not enough to fully clarify both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and clearly identifies the resource ('digital-input lines'), with modifiers that distinguish it from analog acquisition and recording tools. It explicitly states the function and scope, making it distinct from siblings like acquire_analog_voltage or record_analog_voltage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (single software-timed sample from digital lines) but does not explicitly mention alternatives or exclusion cases, such as continuous sampling or analog reads. Context with sibling tools is inferable but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds value by specifying what the status report includes (readiness, safety limits, allowlist state, project warnings), giving the agent a clearer picture of the tool's output without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and key subjects. Every word contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters) and the presence of an output schema, the description sufficiently conveys purpose and scope. It covers all relevant aspects of the status report without needing to detail return values or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description does not need to elaborate on parameters, and the schema is trivially covered by the absence of properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Report') and enumerates the exact information it provides: backend readiness, enforced safety limits, allowlist state, and project warnings. This distinguishes it from sibling tools that focus on device operations rather than server-level status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking server status, but it does not provide explicit guidance on when to use it versus the sibling device-focused tools. There is no mention of exclusions or alternative tools, so usage context is only implied through the nature of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the important behavioral detail that only allowlist-visible devices are returned. This surpasses the annotations by revealing the filtering behavior, though it does not explain edge cases like an empty allowlist or errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that fully conveys the tool's purpose without any wasted words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema present, the description is complete. There is no missing information about inputs or outputs, and the allowlist qualification is sufficient for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4 per the rubric. The description adds no parameter details, but none are needed since the function takes no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('devices'), and clarifies the scope ('visible through the configured device allowlist'), which distinguishes it from sibling tools like list_physical_channels and get_device_details. It clearly communicates what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for listing only allowlisted devices, providing some context. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions beyond the allowlist. There is no explicit reference to sibling tools or conditions requiring their use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only needs to add behavioral context beyond those. It does so by stating 'preserving the supplied numeric code and original message,' which signals that the tool does not modify or rewrite the user's inputs. This adds meaningful behavioral information beyond the annotation-provided safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to understanding the tool's purpose and key behavior. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two parameters and an output schema present (so return values need not be described). The description covers the core functionality and behavioral nuance. No additional context—such as required permissions or edge cases—is necessary for the agent to use it effectively alongside the given schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does by labeling the parameters as 'numeric code' and 'original message,' mapping directly to the schema properties 'code' and 'message.' This adds clarity about the nature of each parameter, though it stops short of explaining optionality or format. The description provides enough semantic grounding given the simple parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Explain a DAQmx error while preserving the supplied numeric code and original message.' It uses a specific verb ('Explain') and resource ('DAQmx error'), and the preservation clause adds a distinguishing detail. The sibling tools are all device I/O operations, so this error-explanation tool is clearly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: this tool is for explaining DAQmx errors, not for interacting with devices. It does not explicitly mention when to use it or provide alternatives, but the context and sibling names make the intended use clear. There are no exclusions or warnings, but the absence of alternatives is acceptable given the straightforward niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![daqmx-mcp MCP server](https://glama.ai/mcp/servers/BrianDavidCouch/daqmx-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BrianDavidCouch/daqmx-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BrianDavidCouch/daqmx-mcp'

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