daq-mcp

by rhit-folayaod

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
Disambiguation4/5
Most tools clearly target distinct resources/actions: device enumeration, channel description, analog read/write, digital read/write, waveform analysis, and self-test. The only potential overlap is between read_analog and monitor_analog—both acquire analog signals and return summary statistics—but their descriptions clarify different use cases (raw samples vs. battery of descriptive statistics).
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (list_devices, describe_device, read_analog, write_analog, etc.). Even self_test fits the command-style, and there is no mixing of camelCase or inconsistent verb forms.
Tool Count5/5
Eight tools cover the core tasks for a DAQ MCP server—device discovery, channel inventory, analog/digital I/O, waveform monitoring, and diagnostics. This is a well-scoped set that avoids bloat while providing all essential operations.
Completeness4/5
The surface provides a full CRUD-like lifecycle for basic DAQ interactions: enumerate, describe, read, write, and test. Minor gaps exist such as no arbitrary analog waveform generation (write_analog only outputs DC) and no continuous acquisition mode, but these are not critical for typical agent use.
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It states the tool 'runs' the self-test and 'reports' pass/fail, but does not disclose whether the operation is read-only, has side effects, or requires device state conditions. This is insufficient for a tool that likely interacts with hardware.
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 two short, focused sentences. The first sentence states the action and outcome, and the second provides usage context. No unnecessary words or repetition.
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?
The tool is simple, and an output schema exists, so return values are covered. However, the description omits parameter semantics and behavioral details (e.g., is the self-test non-invasive?), which are important for an agent deciding to invoke it. The usage tip adds some context, but the overall completeness is only adequate given the tool's simplicity.
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 one required parameter 'device' with no description, and schema description coverage is 0%. The tool description does not explain what 'device' means or how it should be formatted, leaving the agent to infer from sibling tools like list_devices. With no parameter guidance, the description fails to compensate for the schema gap.
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 tool runs the device's built-in self-test and reports pass/fail, which is a specific verb and resource. However, it does not explicitly differentiate from sibling tools like read_analog or read_digital, though the action is distinct in context.
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 provides clear usage guidance: 'Useful as a first diagnostic when reads return unexpected values.' This gives a concrete scenario but does not mention alternatives or exclusions, so it falls short of a 5.
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?
With no annotations provided, the description carries the full burden. It discloses the return aggregation (min/mean/max) and the single vs. multi-sample behavior, but does not explicitly mention non-destructive read-only nature, error conditions, or permissions. The word 'Read' implies safety, but no explicit statement.
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?
Four sentences, front-loaded with the core purpose, followed by parameter guidance and return-value rationale. No wasted words; each sentence earns 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?
Given an output schema exists, the description needn't detail return structures, but it does summarize the aggregation. It covers purpose, key parameters, and return value. Missing an explicit comparison to monitor_analog, but otherwise complete for a read operation.
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 for three of four parameters, giving concrete examples ('Dev1/ai0') and clarifying semantics ('1 = single instantaneous reading'). However, terminal_config is not explained, leaving a gap.
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 opens with a specific verb and resource: 'Read voltage samples from an analog input channel.' This clearly distinguishes it from sibling tools like read_digital and write_analog.
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 explains what the tool does and parameter semantics, but does not explicitly state when to use it over alternatives like monitor_analog. It implies usage context via 'samples' and 'rate_hz', but no direct comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses return behavior: 'Returns available analog input, analog output, digital input, and digital output channels, plus voltage ranges and max sample rates.' This explains what the tool produces. It also implies a non-mutating, read-only nature through the verb 'describe,' though it does not explicitly address error cases or prerequisites.
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 two sentences with no wasted words. The first sentence states the core purpose; the second adds return details and a practical usage tip. It is front-loaded and concise.
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 (one parameter, no annotations) and has an output schema, so the description need not restate output structure. It provides the essential context for selecting and invoking the tool—what it does and when to use it. The main gap is the under-specified 'device' parameter, but given the minimal complexity, the overall context is adequate.
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 coverage is 0%—the schema only lists 'device' as a required string with no description. The tool description does not compensate. It only mentions 'one device' in passing, which hints that the parameter identifies the device but offers no format guidance, source of valid values, or relationship to list_devices. The agent is left guessing how to populate the parameter.
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 purpose: 'Describe one device's full channel inventory.' This is a specific verb (describe) with a well-defined resource (device channel inventory). It distinguishes itself from sibling tools (read, write, monitor) by focusing on inventory discovery rather than data transfer.
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 gives clear usage context: 'Use this to pick valid channel names before reading or writing.' This tells the agent when to invoke it relative to other operations. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals that the tool returns mean, RMS, peak-to-peak, standard deviation, and a downsampled preview rather than full data, and explains the rationale (keeping large acquisitions out of the context window). It does not mention auth, side effects, or error behavior, but for a monitoring read tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core action, the second adds concrete return details and use case, and the third reinforces a key behavioral benefit. No filler or repetition.
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 has moderate complexity (3 params, output schema present). The description covers the main purpose, return contract, and design rationale. The main gap is parameter semantics, but the output schema likely covers return details. Overall it is a solid standalone description.
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 must compensate. It gives no specific explanation of channel, rate_hz, or duration_s beyond the overall waveform context. The parameter names are self-descriptive, but the description adds no meaningful semantics about units, bounds, or relationships, leaving the agent to infer too much.
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 verb ('Acquire'), the resource ('finite analog waveform'), and the result ('return summary statistics'). It explicitly differentiates from sibling tools by saying it returns summary statistics and a downsampled preview instead of the full sample array, which distinguishes it from read_analog.
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?
It provides clear context for when to use the tool: 'Built for the "is my sensor behaving?" question' and emphasizes avoiding large context-window usage. However, it does not explicitly mention when not to use it or name alternatives like read_analog for raw samples.
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?
The description discloses the return format ({channel, value}), which is useful. However, with no annotations provided, it does not cover error behavior, whether the line must be configured as input, or any side effects. The description carries the full burden and offers only basic information.
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 two concise sentences: the first states the purpose clearly, the second provides parameter format and return value. No wasted words.
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?
Given the low complexity (single parameter, output schema existing), the description covers the channel format and return value well. It lacks details on invalid channels or configuration requirements, but these are not critical for a straightforward read operation.
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 schema only says 'channel' is a required string (0% coverage), but the description adds an example format ('Dev1/port0/line0'), providing meaning beyond the bare schema. This compensates for missing schema descriptions, though it could be more exhaustive.
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 'Read the current logic level of a digital input line,' which is a specific verb+resource construction that distinguishes it from siblings like read_analog and write_digital.
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 example channel format ('Dev1/port0/line0') provides clear context for when to use the tool, but it does not explicitly mention alternatives or exclusions, such as using read_analog for analog signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses clamping behavior, the fact that both requested and actual voltages are returned, that clamping is flagged, and that the tool 'never silently changes the value the model asked for' — excellent transparency.
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 two sentences, front-loaded with the core purpose, and every sentence adds meaningful behavioral detail. No fluff or repetition.
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 (2 parameters) and has an output schema, so the description covers the main behavioral aspects well. The lack of parameter-specific details (units, channel format) is a minor gap, but overall the description is complete for a model to select and invoke the tool correctly.
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 must compensate. It adds 'DC voltage' semantics to the voltage parameter but does not explain units, channel format, or the actual AO_VOLTAGE_LIMITS values. The channel parameter receives no additional meaning beyond its name.
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 purpose with a specific verb ('set') and resource ('analog output channel') plus the action ('to a DC voltage'). It distinguishes itself from sibling tools like read_analog and write_digital.
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?
Clear context is provided: this tool is for setting analog output channels. However, there are no explicit exclusions or alternative tool references, though the action is unambiguous enough that an agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it discloses the non-obvious read-back behavior ('read back from hardware, not echoed') and explains why it returns the state. The environment-variable requirement is another important behavioral context. This goes beyond the schema and gives the agent confidence about side effects and verification.
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 two sentences. The first is the core action; the second adds a crucial behavioral note. No wasted words, and the most important information is front-loaded.
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 only two parameters and an output schema. The description explains the action, the prerequisite, and the return value semantics. It doesn't detail channel syntax, but given the simplicity and the presence of an output schema, the description is sufficiently complete for most agents.
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?
Schema coverage is 0% and no parameter descriptions exist. The description implicitly maps value to 'high or low' (true/false) but does not explain the channel parameter format or possible values. This is partial compensation; the value semantics are clear, but channel remains ambiguous.
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 opens with a specific verb+resource: 'Set a digital output line high or low.' This clearly distinguishes the tool from siblings like read_digital (read vs. write) and write_analog (digital vs. analog). The purpose is unequivocal.
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 provides a key usage condition: 'Requires DAQ_MCP_ALLOW_WRITE=1.' This tells the agent when the tool can be used (when write access is enabled). It doesn't explicitly list alternatives, but the context of setting a digital output is clear enough for a simple write operation.
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?
Without annotations, the description carries the disclosure burden. It clearly states that it lists visible devices and enumerates the fields returned, which is useful behavioral context. It does not explicitly state 'read-only' or mention error conditions, but the 'List' verb and focus on discovery make side effects unlikely.
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 two sentences: the first states the core purpose, the second adds return information and a usage hint. Every word is necessary, and it is front-loaded with the primary action.
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 discovery tool with an output schema, this description is complete. It states what devices are listed, what fields are returned, and the recommended invocation order. The 'call this first' guidance integrates it well with the tool family.
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 input schema has zero parameters, so the baseline is 4. The description correctly focuses on output and usage, adding no unnecessary parameter details. It fully aligns with the schema's simplicity.
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 opens with 'List NI DAQ devices visible to this machine,' a specific verb and resource that clearly distinguishes it from siblings like describe_device. It also lists the returned fields (device name, product type, serial number, supported channel types), further clarifying scope.
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?
It provides clear context with 'Call this first — channel names are device-specific,' establishing it as the entry point for device discovery. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a perfect score.
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:

[![daq-mcp MCP server](https://glama.ai/mcp/servers/rhit-folayaod/daq-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rhit-folayaod/daq-mcp)

Score Badge

Copy to your README.md:

[![daq-mcp MCP server](https://glama.ai/mcp/servers/rhit-folayaod/daq-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rhit-folayaod/daq-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/rhit-folayaod/daq-mcp'

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