ignition-mcp-server

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Each tool targets a distinct resource or operation. The 'list_' vs 'get_' pattern clearly separates enumeration from detailed retrieval, and runtime operations (read_tag, write_tag, execute_script, get_history) are distinct from static project inspection tools. No overlapping purposes.
Naming Consistency5/5
All tools use a consistent verb_noun naming convention with underscores (e.g., get_tags, list_views, write_tag). Even 'ping' follows the verb pattern. No mixing of styles or irregular patterns.
Tool Count5/5
17 tools cover both static project exploration (list/get for multiple resource types) and live gateway operations (script execution, history, tag I/O). The scope is well-defined without being overwhelming, and each tool has a clear purpose.
Completeness4/5
The tool set covers the main Ignition project resources (views, scripts, tags, alarms, queries, UDTs) and critical runtime operations. Minor omissions exist (e.g., no tool to list tag provider properties, no update operations) but are reasonable for a read- and query-focused server.
Average 3.8/5 across 17 of 17 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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
This repository is licensed under MIT License.
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 provided, so description carries full burden. It implies read-only listing but does not explicitly state non-destructiveness, permissions, or side effects. Lacks detail on behavior beyond listing.
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, no redundancy. Purpose is front-loaded, and parameter information is clearly structured. No wasted words.
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?
Tool has an output schema (not shown), so return values need not be described. However, missing behavioral aspects like error handling, project format constraints, and any assumptions (e.g., existence of alarms). Adequate but not thorough.
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 description adds meaning to the single parameter 'project_path' (Path to Ignition project directory or .zip export) beyond the schema's bare type string. With 0% schema coverage, this compensates well.
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 lists all alarm pipeline names in an Ignition project, using specific verb 'list' and resource 'alarm pipeline names'. It is distinct from siblings like get_alarm (singular) and list scripts/queries, but does not explicitly differentiate.
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 tool versus alternatives such as get_alarm for details. No context on prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. It only mentions listing names without addressing permissions, side effects, or whether it is read-only.
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 concise sentences, front-loaded with the tool's purpose, then parameter explanation. 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?
Adequate for a simple list tool with an output schema. Could mention that it returns only names and not full UDT definitions, but sufficient for basic understanding.
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?
Despite 0% schema description coverage, the description explains the sole parameter 'project_path' with a clear concept ('Path to Ignition project directory or .zip export'). Adds value beyond the schema.
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 ('List all UDT names') and the resource ('User Defined Type'). It distinguishes from sibling 'get_udt' implicitly, but could be more explicit that this returns only names.
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 tool versus alternatives like get_udt or list_views. Lacks explicit context for optimal usage.
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 provided, so description carries full burden. It describes the operation as a read (get) and explains optional parameter behavior, but does not disclose permissions, side effects, or rate limits. Adequate but not thorough.
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 concise, with a one-line summary followed by structured Args. No unnecessary information. Could be slightly more organized (e.g., bullet points), but no waste.
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 presence of an output schema (not shown), the description need not explain return values. It explains both parameters clearly. For a simple get tool, this is sufficient, though it lacks any cross-referencing or usage notes.
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%, but the description adds meaning: project_path is 'Path to Ignition project directory or .zip export' and udt_name is 'Optional UDT name. If empty, returns all UDTs.' This adds significant value beyond the schema's type-only definitions.
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 'Get UDT definition(s) with member details,' specifying the action and resource. It distinguishes from list_udts by implying detailed output, but does not explicitly differentiate from siblings.
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 provides parameter behavior (e.g., empty udt_name returns all UDTs), but lacks guidance on when to use this tool versus alternatives like list_udts. No exclusions or context for selection are given.
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?
Without annotations, the description should disclose safety aspects (read-only) and output structure, but it only mentions listing names. No information about side effects, permissions, or response format beyond the implied list of strings.
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 with two short sentences, immediately stating the action and listing the argument. Every word is necessary.
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?
While the tool is simple and has an output schema, the description lacks usage guidelines and behavioral transparency, making it incomplete for an agent to fully understand when and how to use it.
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 description adds meaningful context to the single parameter 'project_path', specifying it can be a project directory or .zip export, which is not evident from the schema alone. Schema coverage is 0%, so this is beneficial.
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 'List' and the resource 'named query names' within a given 'Ignition project', making the tool's purpose specific and distinguishable from siblings like 'get_named_query'.
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 provided on when to use this tool versus alternatives, such as 'get_named_query' for full details. The description lacks context for effective decision-making.
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 must carry the full burden. It only says 'Get', implying a read operation, but does not explicitly state read-only nature, side effects, permissions, or error conditions like missing view or invalid path.
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: one line for the main purpose followed by two structured parameter descriptions. No unnecessary text, and all 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?
Given the tool has only 2 required parameters and an output schema exists, the description covers the inputs well. However, it lacks information on error behavior or prerequisites (e.g., does the view need to exist?), but these are acceptable gaps for a simple getter.
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?
With 0% schema description coverage, the description compensates by explaining both parameters: 'project_path' as path to Ignition project directory or .zip, and 'view_path' with examples like 'Overview'. This adds significant meaning beyond the raw 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 states the verb 'Get' and the resource 'Perspective view's component tree, bindings, and structure'. It distinguishes from sibling 'list_views' by focusing on details of a specific view, not listing.
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 provide explicit guidance on when to use this tool versus alternatives like 'list_views' or 'get_tags'. It only implies usage for retrieving a specific view's internal structure.
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 full burden. It only says 'list all scripts... with their scope,' but does not disclose behaviors like reading a directory, required permissions, error handling, or performance implications. This is minimal 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 concise: one sentence for the tool's purpose, one for the parameter. It front-loads the action and resource, with no unnecessary 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 simplicity (1 parameter) and presence of an output schema (not shown but indicated), the description is adequate. It specifies that output includes script names and scopes. Could mention more about output structure, but not required due to output schema.
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%, but the description adds meaning to the 'project_path' parameter: 'Path to Ignition project directory or .zip export.' This clarifies the expected input format, which is not evident from the bare schema type string.
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 'List all scripts in an Ignition project with their scope.' It uses a specific verb ('List') and a specific resource ('scripts'), and it distinguishes itself from siblings like 'get_script' (singular) and 'execute_script' (execution).
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 provides no guidance on when to use this tool versus alternatives like 'get_script' or 'execute_script'. It simply states what it does, leaving the agent to infer usage from context.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action without revealing side effects, required permissions, error behavior, or whether the operation is read-only. This is insufficient for an agent to understand implications.
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 very concise: two sentences plus an Args section. Every part earns its place, and the key information is front-loaded. No wasted words.
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 with one parameter, and an output schema exists (though not shown). The description covers the basic purpose and parameter context, but lacks details on return format, error handling, or behavior with invalid paths. It's minimally adequate but not complete.
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%; the description adds meaning by specifying that project_path is a path to an Ignition project directory or .zip export, which is not in the schema. This is essential for parameter understanding.
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 lists tag provider names in an Ignition project, with examples like 'default' and 'edge'. The verb 'list' and resource 'tag provider names' are specific and distinguish it from siblings that list other entities.
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 retrieving tag provider names but lacks explicit guidance on when to use this tool versus alternatives, or any prerequisites or exclusions. The sibling tools are different, so the purpose is clear, but no when-not context is provided.
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 adds some behavioral context (script runs in gateway scope with access to system.* functions) but does not disclose potential side effects, error handling, or security implications. More transparency would be beneficial.
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 concise and front-loaded, with the key action stated first. The Args section is slightly redundant but adds clarity. No unnecessary sentences are present.
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?
Given the complexity of executing scripts, the description covers the basic requirement but lacks completeness on output format, error handling, and safety considerations. The presence of an output schema helps, but the descriptive text could be more thorough.
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 single parameter 'code' has no schema description (0% coverage). The description adds meaningful information by stating it is Python code to execute on the gateway, which goes beyond the type. However, it lacks details like syntax or length limits.
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 executes a Python script on the Ignition gateway and returns the result. It distinguishes itself from sibling tools like get_script and list_scripts by focusing on execution rather than retrieval.
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 mentions a prerequisite (server started with --gateway-url) but does not provide guidance on when to use this tool versus alternatives like get_script or write_tag. No exclusions or alternative tools are suggested.
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?
With no annotations provided, the description carries full burden. It implies read-only via the verb 'read' but does not disclose behavioral traits such as error handling (e.g., if tag not found), authentication requirements, rate limits, or side effects. The description is minimal in covering expected behaviors beyond the basic operation.
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: two sentences plus the parameter description. Every sentence serves a purpose (purpose, prerequisite, arg details). No wasteful 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 presence of an output schema (which likely describes return values), the description does not need to detail outputs. It covers the input and prerequisite adequately. However, it could briefly mention what the tool returns (e.g., current value), but that is reasonable to leave to the output schema.
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 coverage is 0%, so description must compensate. It explains the one parameter 'tag_path' clearly: it is a string, can include multiple tags comma-separated, and provides an example format. This adds significant value beyond the schema's type definition.
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 action ('Read the current value') and the resource ('tags from a live Ignition gateway'). The verb 'read' is specific, and the resource 'tags' distinguishes it from sibling tools like write_tag (write), get_alarm (alarms), and get_history (history).
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 a necessary prerequisite (server started with --gateway-url and WebDev module). However, it does not explicitly guide when to use this tool versus alternatives (e.g., get_tags, write_tag). The sibling list exists but the description itself lacks explicit 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 provided; description notes necessary setup but does not disclose side effects, rate limits, authentication, or typical error conditions. Limited 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient paragraphs: first sentence states purpose, second covers prerequisites, then clear parameter list with examples. No superfluous content.
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?
Covers prerequisites and parameter formats well. Output schema exists (not shown), so return value details are delegated. Could briefly note that it returns historical data points, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds full details for all three parameters: examples for tag_path, ISO 8601 format for start and end. Maximally compensates for schema 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?
Clear verb 'Query' and resource 'historical tag data' directly indicate the tool's function. Distinguishes from siblings like read_tag (current value) and get_tags (tag metadata).
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?
States prerequisites (server started with --gateway-url, historian configured) but does not specify when not to use or contrast with alternative tools like read_tag.
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 must cover behavioral traits. It does not mention read-only status, side effects, error behavior, or authentication requirements. The description only states the content of the configuration, leaving agents uncertain about safety and failure modes.
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 compact, front-loaded with the main purpose, and includes parameter documentation in a clean docstring format. Every sentence adds value without redundancy.
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 tool's simplicity and presence of an output schema (not shown but indicated), the description covers the main return content. It is sufficient for most use cases, though could add details about error handling or prerequisites (e.g., file system access) for completeness.
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?
Input schema has 0% description coverage, but the tool description compensates by explaining both parameters: 'project_path' is a path to directory or .zip, and 'pipeline_name' comes from 'list_alarms' output. This adds meaningful context beyond raw schema, though more format details (e.g., required permissions) could be included.
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 'Get an alarm pipeline's configuration including stages, notifications, and transitions.' It uses a specific verb ('Get') and resource ('alarm pipeline's configuration'), and distinctly sets it apart from sibling tools like 'list_alarms' which lists alarms but does not retrieve full configuration.
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 implicit usage guidance through parameter descriptions, especially noting that 'pipeline_name' is derived from 'list_alarms output'. This hints at a dependency and when to use this tool after listing. However, no explicit when-not-to-use or alternative tools 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?
No annotations are provided, and the description does not disclose side effects, permissions, or limitations beyond stating what is retrieved. It doesn't contradict annotations since none exist.
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 plus a clear Args list, front-loaded with the main purpose. No extraneous 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?
An output schema exists, so return values are documented. The description covers both parameters adequately and explains the tool's purpose. Slight lack of behavioral details prevents a 5.
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?
With 0% schema description coverage, the description adds meaning for both parameters: project_path (path to project directory or .zip) and query_name (from list_named_queries output). This compensates well for the missing schema descriptions.
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 'Get a named query's SQL, parameters, database connection, and type' with a specific verb and resource. It distinguishes from siblings like list_named_queries (which lists names only) and other get_* tools.
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 after list_named_queries by referencing its output, but lacks explicit when-to-use, when-not-to-use, or alternative tool 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 bears the full burden. It states the tool retrieves source code, which implies a read-only operation, but does not disclose error conditions, permission requirements, or any side effects. The behavior is basic and not misleading, but additional details 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two focused sentences for purpose and two brief parameter descriptions. Every sentence adds value, and the main action 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?
Given the existence of an output schema (which presumably describes the return format), the description does not need to elaborate on return values. It covers the tool's purpose, inputs, and hints at a prerequisite (list_scripts). For a simple retrieval tool, this is nearly complete; a mention of the output being source code would be a minor improvement.
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 has 0% description coverage, but the description adds meaningful explanations for both parameters: project_path is described as a path to an Ignition project directory or .zip export, and script_path is described as a script resource path from list_scripts output. This adds value beyond the schema, though examples or format hints would elevate it further.
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 action ('Get the source code') and the resource ('an Ignition project script'), and distinguishes it from sibling tools like list_scripts (which lists scripts) and execute_script (which runs them). The verb+resource combination is specific and unambiguous.
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 script_path should come from list_scripts output, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any conditions or prerequisites beyond the parameter descriptions.
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 burden of transparency. It states the tool lists paths, which is inherently non-destructive, but does not explicitly mention read-only behavior, authorization needs, or error handling. An output schema exists but the description adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second describes the parameter. No extraneous words, front-loaded with key verb and noun.
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 listing tool with one parameter, the description covers the primary function. However, it lacks details on return value format (though output schema exists) and error behavior. It is adequate but not fully complete.
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 one parameter 'project_path' with type string. The description adds meaning by specifying it as 'Path to Ignition project directory or .zip export', which goes beyond the schema's type-only definition. Schema description coverage is 0%, so the description compensates well.
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 'List all Perspective view paths in an Ignition project', specifying the verb 'list', the resource 'Perspective view paths', and the context 'Ignition project'. This distinguishes it from siblings like 'get_view' which retrieves a specific view.
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 when needing to list view paths but does not explicitly state when to use this tool versus alternatives like 'get_view'. No guidance on exclusion or prerequisites is provided.
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, the description carries full burden. It states the value is sent as-is and gateway handles type coercion, which provides some behavioral context. However, it does not disclose other traits like whether the write is synchronous, reversible, or has 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus structured Args. Every sentence provides necessary information without fluff. It is front-loaded with the primary action and requirement.
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 two-parameter tool with an output schema, the description covers purpose, parameters, and a key behavioral note. It lacks mention of error scenarios or the output format, but the output schema exists so it is not required.
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 coverage is 0%, so description compensates well. It explains tag_path with an example and clarifies that value is a string representation for coercion, adding meaning beyond the schema's type definition.
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 it writes a value to a tag on a live Ignition gateway. The verb 'write' and resource 'tag' are specific, and it distinguishes from sibling tools like read_tag.
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 mentions a prerequisite (server started with --gateway-url) but does not provide explicit guidance on when to use this tool versus alternatives. However, the context of writing tags is clear enough for correct selection.
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 is minimal and does not disclose behavioral traits beyond annotations (none provided). For a health check, it could mention that it is read-only and idempotent, or what the response looks like. However, the simplicity of the tool mitigates the need for extensive detail.
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: 'Health check — verify the server is running.' Every word is essential, and there is no wasted text.
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 (which documents return values), the description is complete enough. It effectively conveys the essential purpose.
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 no parameters, so the description does not need to add parameter information. Baseline for 0 parameters is 4, and the description does not detract from that.
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 'Health check — verify the server is running' clearly states the tool's purpose: a health check to verify server availability. It uses specific verbs and resource, and it is easily distinguishable from sibling tools like 'execute_script' or 'get_alarm'.
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 as a simple health check, providing clear context. However, it does not explicitly mention when to use versus alternatives or any exclusions, but given the tool's simplicity, this is a minor omission.
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 full burden. It implies a read-only operation by describing retrieval, and specifies filtering behavior. It lacks explicit statements about idempotency, error handling, or side effects, but the presence of an output schema mitigates the need for describing return structure.
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, with two introductory sentences followed by a structured arg list. It is front-loaded with the main purpose, and every sentence adds value without redundancy.
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 description covers the essential aspects for a get/retrieve tool with three parameters and an output schema. It references a related tool for provider discovery. It does not cover error scenarios or detailed return structure, but the output schema likely provides that. A small gap is the lack of mention about the return format or pagination if tags are many.
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 so by explaining the purpose of each parameter, including the optional tag_path filtering and the default provider. It adds context (e.g., 'Use list_tag_providers to discover') that goes beyond the schema. However, the format of tag_path (e.g., path separator) is not detailed.
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 action ('Get tags') and the resource ('Ignition project'), and distinguishes from sibling tools like list_tag_providers by specifying the target and optional filtering. It explicitly states the verb and resource, leaving no ambiguity.
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 explains the optional filtering and default provider, and directs users to list_tag_providers for discovery. However, it does not explicitly state when to use this tool versus siblings like list_udts or read_tag, nor does it mention prerequisites like ensuring the project exists or handling invalid paths.
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:

[![ignition-mcp-server MCP server](https://glama.ai/mcp/servers/Nodeblue-AI/ignition-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Nodeblue-AI/ignition-mcp-server)

Score Badge

Copy to your README.md:

[![ignition-mcp-server MCP server](https://glama.ai/mcp/servers/Nodeblue-AI/ignition-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Nodeblue-AI/ignition-mcp-server)

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/Nodeblue-AI/ignition-mcp-server'

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