nodered-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is some overlap among get_flows, get_flows_formatted, and visualize_flows, which all retrieve flow data in different formats. Similarly, find_nodes_by_type and search_nodes both search for nodes but with different scopes. These are not major conflicts but enough to introduce slight ambiguity.
Naming Consistency4/5
The majority of tools follow a consistent verb_noun pattern (e.g., get_flow, create_flow, update_flow, delete_flow). However, 'inject' is a bare verb and 'api_help' is noun_noun, deviating from the established pattern. Overall, the convention is strong and predictable.
Tool Count3/5
With 22 tools, the server is on the heavier side, falling into the 16-25 range that feels somewhat dense. While the tools cover a comprehensive set of Node-RED operations, the count is slightly beyond what might be considered lean, though it is defensible given the breadth of the domain.
Completeness4/5
The tool surface provides solid coverage for managing flows (create, read, update, patch, delete), runtime state, node modules, and node search. Missing operations include flow import/export and credential management, but these are not critical gaps for typical workflows. Overall, the surface is well-rounded with only minor omissions.
Average 3.6/5 across 22 of 22 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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?
With no annotations, the description carries the full burden. It simply says 'Update a single flow' and 'Returns: Confirmation message', without disclosing whether it replaces the entire configuration, whether it's destructive, or any side effects. The mutation behavior is implied but not detailed.
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 compact with a clean Args/Returns structure. It has no fluff, but the terseness comes at the cost of missing necessary detail.
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?
For a mutation tool with many siblings, the description provides no usage context, no distinction from similar tools, and minimal parameter explanation. The presence of an output schema doesn't compensate for the lack of guidance on when to use this tool.
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 descriptions are empty (0% coverage), so the description must compensate. It provides only restatements: 'flow_id: Flow ID' and 'flow_json: Flow configuration as JSON string'. The latter adds that it's JSON, but doesn't explain the expected structure or semantics beyond the type string. This is minimal value.
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?
Description states 'Update a single flow' with a clear verb and resource. It distinguishes from the plural sibling 'update_flows' by emphasizing 'single'. However, it doesn't differentiate from 'patch_flow', so it's clear but not fully distinctive.
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 explicit guidance on when to use this tool vs alternatives like patch_flow or update_flows. The 'single flow' wording hints at a batch alternative but doesn't state it. No usage scenarios or prerequisites.
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?
The description discloses the destructive nature through the verb 'delete' but provides no additional context about side effects, irreversibility, permissions, or impact on related data. With no annotations present, the description carries the full burden and fails to add meaningful behavioral detail.
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 well-structured, with a clear one-line purpose and an Args/Returns breakdown. It is front-loaded and wastes no words, though it may be too terse to be fully informative.
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 description is insufficient for a complete understanding of the tool. It lacks usage guidelines and behavioral transparency. Although the tool is simple and has an output schema, the description does not cover important aspects like when to use or safety considerations, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description restates the parameter name (flow_id) as 'Flow ID to delete', which adds minimal semantic value beyond the schema's bare string type. Since schema coverage is 0%, the description should compensate with richer meaning, but it merely echoes the parameter name without explaining constraints or context.
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 'Delete a flow' uses a specific verb and resource, clearly indicating a destructive operation. It distinguishes from sibling tools like update_flow, patch_flow, and create_flow by the explicit delete action.
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. There is no mention of prerequisites, exclusions, or comparison with other flow-related tools, leaving the agent to infer usage solely from the name.
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, the description must carry full disclosure. It only states the action and return value, but does not disclose any behavioral traits such as read-only nature, permission requirements, or side effects. This is minimal disclosure.
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 exceptionally concise, with a clear verb-first sentence and a minimal return note. It is appropriately front-loaded and contains no unnecessary 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?
For a simple zero-parameter getter, the description is adequate, but it could benefit from clarifying what 'runtime settings' includes. The presence of an output schema mitigates the need to specify the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already documents everything. The description doesn't need to add parameter semantics; per the rubric, the baseline for 0 params is 4.
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 identifies the action ('Get') and the resource ('Node-RED runtime settings'), which is specific enough to distinguish from sibling tools focused on flows and nodes. However, it lacks additional context about what the settings pertain to, making it slightly less than a 5.
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 for when to use this tool versus alternatives. The description simply states what it does without any contextual advice, exclusions, or conditions.
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, and the description only states the action and return type. It does not disclose read-only status, permissions, or any side effects, leaving the agent to infer the behavior from the word 'List'.
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, front-loaded with the action, and the return type is given. 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?
Given the tool's low complexity (0 params) and the presence of an output schema, the description is adequate but misses the opportunity to clarify the distinction between flow tabs and flows, and lacks usage context.
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 zero parameters, the schema covers all parameter information (100%). The baseline of 4 applies, and the description adds no extra parameter details but none are needed.
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 uses the specific verb 'List' and identifies the resource 'flow tabs', which is distinct from sibling tools that deal with flows generally. However, it doesn't explicitly differentiate from get_flows or clarify the relationship, so not a 5.
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 sibling tools like get_flows or visualize_flows. The intended use case is implied by 'List all' but not explicitly 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?
With no annotations, the description carries full responsibility. It only mentions creating a flow and returning a result with a new flow ID, but omits side effects, error conditions, idempotency, or permissions.
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, using a clear 'Args' and 'Returns' structure with no redundant information. Every line serves a purpose.
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, and the description provides the essential information. However, it could be more complete by clarifying the flow_json format and any behavioral expectations.
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 the description adds a basic meaning for flow_json as 'Flow configuration as JSON string', which is helpful but lacks detail about the expected structure.
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 explicitly states 'Create a new flow' with the resource and action clearly identified, distinguishing it from siblings like update_flow and delete_flow.
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, nor any exclusions or prerequisites. The usage is only implied by the tool's name and simple description.
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. It only mentions the return type ('List of matching Node objects') but does not disclose read-only behavior, possible errors, case sensitivity, or performance considerations. The read-only nature is implied by 'find' but not explicitly stated.
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, front-loaded with the main purpose, and uses a clean Args/Returns structure. Every sentence serves a clear function, with 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?
Given the tool's simplicity (one parameter, output schema exists), the description provides a minimal but adequate overview. However, it omits usage guidelines and behavioral caveats, leaving some gaps. It is sufficient for basic invocation but not fully contextual.
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 the description adds a basic explanation for node_type ('Node type to search for'), which is more than the raw schema. However, it lacks examples, allowed values, or exact matching semantics, so it only partially compensates for the lack of 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 'Find all nodes of a specific type,' with a specific verb (find), resource (nodes), and scope (type filtering). This distinguishes it from sibling tools like get_nodes and search_nodes, which imply broader or different search behavior.
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 alternatives. The description does not mention when to prefer it over get_nodes or search_nodes, nor any distinguishing criteria beyond the name itself.
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, the description carries the full burden of disclosing side effects. 'Trigger an inject node' implies an action that could cause downstream effects (e.g., starting a flow), but no behavioral details are provided. The only additional information is the return value ('Confirmation message'), which is minimal and does not disclose potential consequences or permissions required.
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 exceptionally concise, using a clear Docs-style structure with Args and Returns sections. Every line serves a purpose, and there is no repetition or fluff. It is easy to parse quickly.
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 tool with one parameter and a clear action, the description covers the essential aspects: what it does, the input parameter, and the return type. Given the presence of an output schema (though not shown) and the trivial complexity, this is sufficient for basic invocation. However, it lacks any context about preconditions or why one would use an inject trigger, leaving some completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage (0%), so the description must compensate. It does explain that node_id is the 'Inject node ID to trigger,' adding basic meaning beyond the schema's bare string type. However, the explanation is somewhat tautological and lacks further qualification (e.g., how to find the ID, if it must be a specific UUID). It meets the minimum but does not richly elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Trigger an inject node.' This is a specific verb+resource combination that unambiguously distinguishes it from sibling tools like 'get_flows' or 'update_flow'. Even without context, the action and target are explicit.
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. The description gives no context about scenarios where triggering an inject node is appropriate or when other flow-manipulation tools would be preferred. This omission leaves the agent without decision support.
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 the disclosure burden. It states the return type (NodeModule with version and node sets) and implies read-only behavior via 'Get', but does not cover error conditions, permissions, or what 'node sets' means. This is adequate but not rich.
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 brief and well-structured with a one-sentence summary followed by Args and Returns sections. Every line serves a purpose, with no filler.
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 getter with an output schema, the description is mostly complete: it states the input and return type. It lacks usage context and edge-case behavior, but given the tool's simplicity, it is sufficient.
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 only defines module as a string, and the description merely restates it as 'Node module name' without adding examples, formatting rules, or constraints. It is minimal compensation for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('information about a specific node module'), distinguishing it from sibling tools like get_nodes (which likely lists all nodes) or search_nodes. The singular 'specific' clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to prefer this tool over alternatives such as get_nodes or search_nodes. It does not mention prerequisites, context, or exclusions, leaving usage ambiguous.
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 burden of behavioral disclosure. 'Get list' implies a read-only operation, and the return type is mentioned, which is helpful. However, it lacks detail on whether the list includes global vs local modules, permission requirements, or potential error conditions.
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 that front-load the purpose and then specify the return value. There is no wasted wording or redundancy, and every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with an output schema available, the description is largely complete. It states what is returned and the main purpose. It could be slightly more complete by adding a note about whether the list is filtered or includes all installed modules, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%, so the schema fully documents the input surface. The description adds no parameter details, but none are needed. The baseline of 4 applies because there are no parameters to explain.
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's action ('Get list of installed node modules') and identifies the resource (installed node modules). It also mentions the return type (NodeSet objects), which adds clarity. However, it does not explicitly differentiate itself from siblings like get_node_info or search_nodes, so it misses the top score.
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 such as get_node_info, find_nodes_by_type, or search_nodes. It simply states what the tool does without any 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 must fully disclose behavior. It states that this is an update operation and returns a confirmation message, but it does not describe side effects, potential destructive impact, required permissions, or how deployment_type values affect behavior. For a batch-update tool, this is a significant transparency 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?
The description is short, front-loaded with the core purpose, and contains only necessary sections (Args and Returns). There is no redundant or vague filler.
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?
With only 2 parameters and an output schema present, the tool is relatively simple, but the description omits usage context, definitions of the deployment_type values, and potential side effects of updating all flows. It is minimally viable 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%, and the description compensates with an Args block: flows_json is described as a flow configuration JSON string, and deployment_type lists valid values (full, nodes, flows, reload) and the default. This adds 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 uses a specific verb ('Update') and clearly identifies the resource and scope: all flows, with a deployment type. This distinguishes it from siblings like update_flow (singular) and patch_flow.
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 explicit guidance on when to use this tool versus update_flow or patch_flow. The phrase 'all flows' implies a batch operation, but no alternatives, prerequisites, or exclusions 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?
Without annotations, the description carries the burden of behavioral disclosure. It does add context by stating the return value includes 'nodes, configs, and subflows.' However, it lacks details about error behavior (e.g., flow not found) or side effects, and it does not explicitly confirm read-only behavior.
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 well-structured and concise: a one-sentence purpose, then Args and Returns sections. Every element earns its place with no 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?
An output schema exists, so detailed return values are already covered. The description provides a high-level return summary and parameter description, making the tool adequately documented. Missing usage guidance and error behavior, but for a simple one-parameter getter, this is nearly complete.
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. The description provides 'flow_id: Flow ID,' which merely restates the parameter name and adds no semantic value about format, where to find it, or constraints. This is insufficient compensation for a schema without 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 single flow by ID' with a specific verb (get), resource (flow), and scope (single by ID). It distinguishes this tool from sibling tools like get_flows (plural) and get_flows_formatted.
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 a specific flow ID is known, but it does not explicitly mention when not to use it or point to alternatives like get_flows. There is no direct guidance on choosing between this and sibling tools.
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 the burden of behavioral disclosure. It mentions that searching covers node properties and that omitting 'property' searches all properties, which is useful. It also states the return type, but does not explicitly confirm read-only behavior or address permissions/rate limits, leaving gaps.
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 well-organized with Args and Returns sections. Every sentence contributes operational detail, and there is 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?
For a simple search tool, the description adequately covers purpose, parameters, and return value. However, it lacks guidance on when to use it instead of sibling tools and does not mention edge cases or limitations, so it is not fully complete.
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?
The schema has no parameter descriptions, but the description fully explains 'query' as the string to search for in node properties and 'property' as an optional filter that defaults to searching all properties. This adds significant meaning beyond the raw schema and fully compensates for the 0% schema coverage.
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 searches for nodes by name or properties, using the specific verb 'Search' and identifying the resource. However, it does not differentiate from sibling tools like find_nodes_by_type, so it lacks explicit sibling distinction.
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 such as get_nodes or find_nodes_by_type. It only explains the basic operation without any contextual usage instructions.
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 the full burden. It implies a read-only operation by using 'get' and specifies the return type, but it does not explicitly state that there are no side effects, nor does it mention any error conditions or permissions. This is adequate for a simple getter but lacks explicit safety disclosure.
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, consisting of two short sentences. It front-loads the primary purpose and adds only necessary return information without any fluff or 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 that the tool takes no parameters and has an output schema, the description is mostly complete. It provides the core purpose and return type, but does not mention the relationship to set_flows_state or elaborate on the meaning of start/stop. The output schema likely covers return details, so this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty. The baseline for 0 params is 4, and there is nothing additional to explain. The description does not need to add parameter semantics because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Get the current flows runtime state.' It further clarifies the returned data as 'FlowState with current state (start/stop),' making it distinct from sibling tools like set_flows_state or get_flows.
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 explicit guidance on when to use this tool versus alternatives. It does not mention that set_flows_state should be used for changing state, nor any other exclusions or context. The intended usage is only implied by the 'get' verb.
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. It mentions the tool changes the module's enabled state and returns an updated NodeModule object, but it does not specify side effects, error conditions, permissions, or persistence. This is minimal but not misleading.
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 well-structured with Args and Returns sections. It states the purpose up front and keeps every sentence useful with no 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 low complexity (two simple parameters, no nesting) and the presence of an output schema, the description covers the essentials: purpose, parameter meanings, and return type. It lacks usage context and side-effect details, but this is a relatively simple tool, so the burden is reduced.
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?
The description adds clear meaning to both parameters: 'module' is specified as the Node module name, and 'enabled' is explained as a boolean to enable or disable. This goes beyond the schema's bare type definitions, making parameter usage unambiguous.
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 states 'Enable or disable a node module' with a specific verb and resource, clearly distinguishing this tool from sibling tools like get_nodes or update_flow. The args and return are also explicitly mentioned.
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, nor does it mention any prerequisites, exclusions, or context. It only states what the tool does, leaving usage decisions to inference.
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 (markdown) and content (node counts and types per tab), which is useful. However, with no annotations provided, it does not explicitly state that the operation is read-only, mention permissions, or describe any side effects. It offers minimal but adequate behavioral context for a visualization tool.
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 exceptionally concise, using two short sentences to convey the purpose and return format. It is front-loaded with the core verb and resource, and every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an existing output schema, the description completely covers what the tool does and what it returns. It specifies the exact output format (markdown) and the breakdown details (node counts and types per tab), making it self-sufficient for an agent to invoke and interpret results.
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, and the description correctly implies that no arguments are needed. Since there are zero parameters, the baseline score of 4 applies, and the description needs no additional parameter-level detail.
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 a specific verb ('Visualize') and resource ('flow structure') with a distinctive output format ('markdown with per-tab breakdown'). This distinguishes it from sibling tools like get_flows_formatted or get_flow, which might also return flow data but without the per-tab breakdown emphasis.
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. It does not mention situations, exclusions, or related tools, leaving the agent to infer appropriate usage solely from the tool name and minimal description.
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. It discloses that the tool returns a DiagnosticsResult, but does not mention side effects (likely none), prerequisites, or what specific diagnostics are included. Minimal but not misleading.
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 action and return type. Every word earns its place; no unnecessary detail.
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 zero-parameter read-only diagnostics tool with an output schema, the description is sufficient. It could mention typical use cases, but the simplicity makes it complete enough for an agent to understand when to call 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 tool has zero parameters, so there is nothing to explain. Description correctly omits parameter details, and the schema covers the absence of parameters. Baseline for 0 params is 4.
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 gets Node-RED diagnostics information with a specific verb and resource. No sibling tool covers diagnostics, so it is distinct 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 usage (when you need diagnostics) but does not explicitly state when to use it versus alternatives. Since no alternative diagnostics tool exists among siblings, the lack of explicit guidance is acceptable but still a gap.
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. It discloses that the tool returns a FlowList grouped by tabs/nodes/subflows with summary stats, which is useful behavioral context. However, it does not mention any side effects, performance implications of fetching all flows, or authentication requirements.
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, with exactly two sentences. The first line is a clear summary, and the second line specifies the return structure 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?
For a zero-parameter getter with an output schema, the description is reasonably complete. It covers the scope (all flows), the return structure, and the grouping. However, it lacks guidance on how this tool differs from get_flows_formatted and does not mention any pagination or truncation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers 100% of the parameter space. The description adds no parameter-specific semantics, but none are needed.
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 gets all flows with summary statistics and specifies the grouping (tabs/nodes/subflows), distinguishing it from sibling get_flow (single) and get_flows_formatted. The verb 'Get' and resource 'flows' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve all flows for summary/overview purposes, but it does not explicitly state when to use it over alternatives like get_flows_formatted or visualize_flows, nor any exclusions. The 'Returns' line provides context but no explicit usage 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?
With no annotations, the description carries the full burden. It discloses the return format (FlowSummary with tabs/nodes/subflows grouped and counted) but does not mention side effects, permissions, or limitations. As a get operation, it is implicitly read-only, but explicit confirmation would strengthen this.
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, consisting of two sentences plus a 'Returns:' block. It is front-loaded with the purpose and the return details are clearly structured, with no redundant or irrelevant 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?
The tool is simple with no parameters and an output schema that likely documents return values. The description provides sufficient detail for a basic getter, but it lacks explicit comparison to sibling tools like get_flows, leaving some ambiguity about when to select this tool over others.
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 accepts zero parameters, so the schema fully covers parameter semantics. The baseline for 0 parameters is 4, and the description does not need to add parameter-specific information; it correctly contains none.
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 does 'Get flows with formatted summary and grouped data,' using a specific verb ('Get') and resource ('flows') with a distinct focus on formatting/grouping. This differentiates it from sibling tools like get_flows, which likely returns raw flows.
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 tool is used when a formatted summary is desired, but it does not explicitly state when to use it versus alternatives like get_flows or get_flows_state. No exclusions or alternative recommendations are 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?
The description discloses the return structure (LayoutReport with issues, counts, summary) and the optional node_ids scoping. However, it does not explicitly state that the operation is read-only or describe any side effects, permissions, or rate limits. With no annotations, the description carries the full burden but remains silent on these behavioral aspects.
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 well-structured with a concise summary followed by Args and Returns blocks. It avoids unnecessary words and presents information in a scannable format.
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 tool with two parameters and an output schema, the description covers the essential information: what it lints, the parameters, and the return type. However, it omits explicit safety details (e.g., read-only) and does not elaborate on the format of node_ids beyond 'JSON array.' Still, given the output schema exists, the description is reasonably 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 description explains both parameters in the Args section: flow_id as 'Flow ID to lint' and node_ids as 'Optional JSON array of node IDs to scope the check.' This adds meaning beyond the bare schema, which provides no descriptions. It clarifies the purpose and optionality of node_ids, although the schema defines it as a string but the description indicates JSON array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Lint a flow's node layout for overlaps, spacing, and wire crossings.' This specific verb-resource combination distinguishes it from sibling tools like visualize_flows (visualization) and get_diagnostics (general diagnostics).
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?
No explicit usage guidance is provided. There are no statements about when to use this tool versus alternatives like get_diagnostics or visualize_flows. The usage is implied by the term 'lint,' but the description does not clarify when this check is appropriate or mention any 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 full responsibility for disclosing behavioral traits. It states the action ('set') and valid states, but does not disclose side effects, permissions, reversibility, or error behavior. For a state-changing operation, this lacks sufficient 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, with a clean Args/Returns structure. Every word adds value, and there is no redundancy or fluff.
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 1-parameter tool with an output schema, the description covers the essentials: action, parameter semantics, and return type. It does not elaborate on context or caveats, but the tool's simplicity means it is reasonably 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?
With schema coverage at 0%, the description compensates by explaining the 'state' parameter and enumerating valid values (start, stop). This is essential information not present in the schema. It could be improved by describing what each state does, but it's adequate for a single-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and clearly identifies the resource ('flows runtime state'), distinguishing it from sibling tools that modify flow definitions (update_flow, patch_flow) or retrieve state (get_flows_state).
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 makes the use case clear: set the runtime state, with valid values start/stop implying the tool is for starting/stopping flows. It does not explicitly mention alternatives or exclusions, but the context is sufficient for most agents.
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?
No annotations are provided, so the description carries full burden. It discloses the internal process ('Fetches the current flow, applies operations, and updates it') and lists supported operation types with examples, as well as the return type. This goes beyond a simple 'update' but omits details about error handling, atomicity, and permissions, preventing a higher score.
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 appropriately sized, with a clear opening verb, an efficiency note, and structured Args/Returns sections. The extensive operation examples are justified by the complexity. No redundant 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?
The description covers the tool's purpose, usage context, operation syntax, and return value, which is comprehensive for a 2-parameter tool. It falls short only in clarifying the string vs JSON array representation and not addressing potential errors, but overall it is complete enough for most use.
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% (no parameter descriptions in schema), so the description must explain parameters. It does explain flow_id and operations, and details the operations format with examples. However, there is a mismatch: schema says operations is a string, while the description describes it as a 'JSON array', which could confuse an agent. Thus, the compensation is strong but flawed.
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 'Apply incremental patch operations to a flow', a specific verb+resource statement. It also explicitly contrasts with update_flow, noting efficiency for small changes, which distinguishes it from sibling tools.
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 states 'Much more efficient than update_flow for small changes', providing a clear comparative guideline. However, it does not explicitly specify when not to use it or mention other alternatives, so the guidance is strong but not exhaustive.
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 bears full responsibility for behavioral disclosure. It clearly states the return format ('Markdown table of API endpoints and their MCP implementation status'), which is a key behavioral trait. While it does not mention side effects, the tool is a read-only reference, and the description adequately implies that.
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, each earning its place: the first states the purpose, the second specifies the output format. No unnecessary words or repetition.
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 parameterless reference tool with an output schema, the description is complete. It explains what the tool does and what it returns. There are no missing prerequisites, side effects, or complex behaviors to disclose, and the output schema covers detailed return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is nothing to explain beyond what the schema already shows, and the description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get Node-RED API endpoint reference with implementation status.' This is a specific verb (get) plus a clear resource (API endpoint reference) and a distinguishing detail (implementation status). It differentiates from sibling tools like get_flows or get_nodes, which concern runtime data rather than API 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?
The description implies usage: an agent would use this when needing an API endpoint reference or implementation status. However, it does not explicitly state when to use this tool over alternatives or provide exclusions. The siblings suggest a broader context, but no explicit guidance is given.
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:

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

Score Badge

Copy to your README.md:

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

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