MCP PLC Core

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are mostly distinct: read_sensor, get_alarms, get_status, get_setpoints, and write_setpoint each target a specific domain area. The main overlap is get_all, which subsumes the individual getters, potentially confusing an agent about whether to call it or individual tools, though descriptions make the distinction reasonably clear.
Naming Consistency4/5
Naming follows a consistent verb_noun pattern: read_sensor, get_alarms, get_status, get_setpoints, write_setpoint, get_all. Minor inconsistency exists with 'read' vs 'get' for data retrieval (read_sensor uses read while others use get), but this is a small deviation and the pattern is otherwise uniform.
Tool Count5/5
Six tools is a well-scoped set for a PLC control server, covering the essential read and write operations without bloat. Each tool serves a clear purpose, and the count is appropriate for the domain.
Completeness4/5
The surface covers reading sensors, alarms, status, and setpoints, plus writing setpoints with safety validation. Notably missing are operations for controlling outputs (writing discrete/analog output values) and acknowledging alarms, which are common PLC tasks. However, get_all consolidates reads, and setpoint writing is the safety-relevant write path.
Average 3.1/5 across 6 of 6 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 carries the full burden of behavioral disclosure. It only says 'get current setpoint values' with no mention of return format, whether this is a read-only operation (though implied by 'get'), rate limits, or any side effects. For a read tool, this is minimally OK but lacks any behavioral detail beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it's under-specified rather than efficiently specified. There is no elaboration that would help an agent decide to use it. The brevity is good, but the content is minimal to the point of being merely functional.
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 no output schema, no annotations, and very brief description, the tool is somewhat under-documented. The agent cannot know what units setpoints are in, whether multiple setpoints are returned at once, or how to interpret the results. Sibling tools like get_status and read_sensor suggest a richer context that this description doesn't clarify.
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 0 parameters and no output schema, so there is nothing for the description to document regarding parameters. With 0 parameters, the baseline of 4 applies since there are no parameter semantics to convey. The description correctly implies no parameters are needed to retrieve all setpoints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get current setpoint values,' which identifies a verb+resource but is very generic. Given siblings like get_status, get_alarms, and get_all, the description doesn't clearly distinguish what distinguishes setpoints from other values. It's not a tautology, but it's a minimal statement of purpose without scope or differentiation.
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?
There is no guidance on when to use this tool versus siblings like get_status or read_sensor. No context about when setpoints would be relevant versus when status or sensor readings would be the right choice. The description implies it's for reading setpoint values but provides no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description states it returns 'active alarms' but doesn't disclose whether alarms are cleared after being read (destructive read), whether it returns time stamps, severity levels, or how many alarms are returned max. For a read operation on potentially stateful PLC data, this is a gap.
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?
One concise sentence with zero waste. It states exactly what the tool does with minimal, efficient language.
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 no annotations and no output schema, the description must compensate for contextual completeness. It doesn't describe the return format (list structure, fields per alarm), whether any filtering exists, or behavioral effects like what 'active' means relative to acknowledgment state. For a tool with no schema detail, this is thin.
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 0 parameters, and schema coverage is 100% (empty schema fully describes the inputs). With no parameters, there is nothing further to explain, so the baseline score of 4 applies. No param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clear: 'Get all active alarms from the PLC.' The verb 'get' + resource 'active alarms' + source 'PLC' is specific. However, it doesn't distinguish from siblings like 'get_all' or 'get_status', which could overlap in meaning.
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?
No guidance on when to use this vs alternatives. Given siblings like 'get_all' and 'get_status', there's ambiguity about whether this returns only active alarms or also historical/cleared alarms, and how it differs from get_all. No when-to-use or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description does not state whether the operation is read-only, what the response format looks like, whether it requires authentication, or latency/rate implications. For a system status tool this is a notable gap—the agent cannot anticipate the return payload structure.
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 efficient sentence with zero waste. It is front-loaded with the verb and resource. Appropriate for a zero-parameter tool, though it could add useful behavioral details without bloating.
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?
For a zero-parameter tool with no output schema and no annotations, the description is minimal but somewhat adequate. However, since there is no output schema, the description should explain what 'overall status' returns (e.g., running state, error codes, uptime) so the agent can interpret the result. The absence of return-value detail and distinction from get_all are gaps.
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 0 parameters, so the schema carries no burden and the description needs no parameter explanations. Per the rubric, 0 params yields a baseline of 4. The description needs to do nothing here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get overall PLC system status' with a specific verb (get) and resource (PLC system status). It is moderately clear, but vague—'overall status' doesn't specify what fields or aspects are included, making it hard to know exactly what will be returned. It does distinguish somewhat from siblings like read_sensor (sensor reading) and get_alarms (alarms), given the 'overall PLC system' scope, but not crisply.
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?
No guidance is given on when to use this tool versus alternatives. With siblings like get_all, get_alarms, and read_sensor, there is ambiguity about whether get_status overlaps with or complements get_all. No when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description does not state whether this is a blocking/real-time read, whether it polls or returns cached values, what units the value is in, or what error cases look like (e.g. nonexistent sensor name). For a read operation with no annotation coverage, this is thin.
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 efficient sentence with zero waste. It's appropriately brief for a simple one-parameter tool. Could arguably include a bit more behavioral context, but conciseness itself is excellent.
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 is simple (1 param, no output schema, no annotations), but it's still incomplete. There's no mention of return value format, units, whether invalid sensor names produce errors, or how readings relate to the get_all tool that likely returns multiple sensor values. Given the sibling set includes get_all, some differentiation about when to use read_sensor vs get_all would add significant value.
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 description coverage is 100%, so the schema already documents the 'sensor' parameter with examples (temperature, pressure, motor_speed). The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema handles the heavy lifting for the single parameter.
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 states 'Read a sensor value from the PLC' with a specific verb (Read) and resource (sensor value from PLC). It distinguishes from siblings which handle alarms, status, setpoints, and writes. However, it doesn't fully clarify what 'value' entails (e.g. current reading only, not history), though the purpose is fundamentally clear.
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 provides basic context ('from the PLC') but no explicit guidance on when to use this tool versus siblings like get_status or get_all. No exclusions or alternatives are mentioned. Usage is implied as 'when you need a sensor reading' but no when-not-to-use information is given.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description discloses that the tool performs validation against safety limits, which is useful. However, it doesn't disclose what happens on validation failure (rejected? error?), whether the write is immediate or buffered, whether it affects other state, or if specific permissions or connection are required. For a write/mutation tool with zero annotation coverage, this is a moderate gap.
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?
Two sentences, zero waste. The description front-loads the core action and adds the safety-validation qualifier efficiently. Every word earns its place.
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?
For a 2-param mutation tool with no output schema and no annotations, the description provides the core purpose and safety validation but leaves open important questions: Does the write persist? What happens on validation failure? Is the value range documented anywhere? Given it's a write operation with safety implications, it could reasonably describe the failure behavior or value-range constraints.
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 description coverage is 100%, so the schema already documents both parameters (value = New setpoint value, parameter = Parameter name with examples). The description adds the key constraint that writes are validated against safety limits, which gives context about value constraints. However, it doesn't specify what the safety limits are or how violations are handled, and the examples in the schema ('temperature, pressure, speed') are more helpful than anything in the description.
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 states a clear verb+resource pair ('Write a setpoint value to the PLC') and adds a distinguishing detail about safety validation. It clearly separates from sibling read-focused tools like read_sensor and get_setpoints. However, it doesn't explicitly name the sibling alternative for reading setpoints, which would strengthen differentiation.
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 this is for writing values while siblings handle reading (read_sensor, get_setpoints), so the contrast is implicit. However, it provides no explicit when-to-use vs when-not-to-use guidance, no mention of prerequisites (e.g., connection state), and doesn't name alternatives explicitly. The 'validates against safety limits' hint implies caution but isn't developed into guidance.
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?
No annotations are provided, so the description must carry the behavioral burden. It describes the data categories returned but doesn't disclose size/volume implications of fetching everything at once, response format, or whether this is a heavier/longer operation than granular reads. For an aggregate read tool, it adds reasonable value but doesn't fully disclose behavioral traits beyond listing return contents.
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?
One tight sentence that front-loads the purpose ('Get all PLC data at once') and enumerates the covered categories. Zero wasted words, perfect for a zero-parameter bulk retrieval tool.
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?
This is a simple zero-parameter tool with no output schema. For an aggregate getter, the description enumerates the categories of data returned, which is sufficient. It doesn't hurt that the siblings clarify the decomposition; describing return contents for a no-input bulk tool is reasonably complete even without specifying response formatting.
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 0 parameters and 100% schema coverage (empty properties), so the schema provides no parameter meaning. The description compensates by describing what data is returned. With no params to document, the baseline is 4, and the description fulfills this by enumerating the data domains it retrieves.
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 states it gets 'all PLC data at once' and enumerates the categories (sensors, alarms, status, setpoints, outputs). This clearly differentiates it as the bulk fetcher versus the more specific sibling tools like read_sensor or get_alarms. It doesn't name a specific sibling but the phrase 'at once' distinguishes its aggregate scope.
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 this is the when-you-want-everything tool, referring to 'all PLC data at once,' which contrasts implicitly with the granular sibling tools. However, it doesn't explicitly state when NOT to use it or suggest alternatives (e.g., 'use read_sensor for a single sensor'). The usage guidance is implied through the 'at once' framing rather than stated.
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:

[![mcp-plc-core MCP server](https://glama.ai/mcp/servers/Maxkrempl/mcp-plc-core/badges/card.svg)](https://glama.ai/mcp/servers/Maxkrempl/mcp-plc-core)

Score Badge

Copy to your README.md:

[![mcp-plc-core MCP server](https://glama.ai/mcp/servers/Maxkrempl/mcp-plc-core/badges/score.svg)](https://glama.ai/mcp/servers/Maxkrempl/mcp-plc-core)

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/Maxkrempl/mcp-plc-core'

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