lcm2m-caddis-mcp

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation5/5
All tools have clearly distinct purposes: get vs list for single vs multiple entities, and specialized tools like caddis_get_tree for hierarchy, caddis_batch for batching. Descriptions explicitly guide when to use each one, minimizing confusion.
Naming Consistency5/5
All tools follow the consistent pattern 'caddis_<verb>_<noun>' with snake_case. Verbs are uniformly 'get' for single entities and 'list' for multiple, with only minor outliers like 'caddis_get_tree' and 'caddis_batch' that still fit the pattern.
Tool Count3/5
31 tools is on the high side, exceeding the typical recommended range of 3-15. However, the domain of manufacturing monitoring is rich and warrants many specialized queries. The count is justified but still feels heavy; it's borderline between 2 and 3.
Completeness3/5
The server covers a wide range of read-only operations for equipment, org units, alarms, tags, runs, etc. However, it lacks any write operations (create, update, delete), which is a notable gap if full lifecycle management is expected. For a read-only monitoring API, it is reasonably complete.
Average 4/5 across 31 of 31 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld hints. The description adds minor value by confirming the response contains inheritance and timezone info, but does not elaborate on rate limits, side effects, or authorization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise, but the lengthy TOON-format tutorial is excessive and dilutes the core purpose. It should be a separate guide or referenced.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must detail the return structure. While it explains the TOON format, it omits what fields the schedule contains (e.g., events, time slots). The example uses 'equipment' which is misleading for an org unit schedule.
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 fully describes the single parameter (orgUnitId). The description does not add further meaning, achieving baseline for 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns a schedule with inheritance source and timezone, but fails to explicitly differentiate from sibling tools like caddis_get_org_unit_utilization. The purpose is clear enough but not sharp.
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 vs alternatives (e.g., other schedule tools). The tool's context is implied by name only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the TOON encoding format details, which is useful but goes beyond minimal behavioral disclosure. No mention of potential side effects, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear purpose sentence but then includes a lengthy TOON encoding tutorial (example and bullet points) that is excessive for the tool description, making it top-heavy and not concise.
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?
No output schema is provided, so the description must explain return values. While it explains the TOON format, it does not specify the exact fields returned for excessive downtime events (e.g., shift time, duration, reason). The example given is for a different tool, leaving ambiguity.
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?
Input schema has 100% coverage with descriptions for all three parameters. The description only repeats that start and end are required, adding no new semantics beyond what the schema already provides.
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 'shifts where a piece of equipment had excessive downtime (XSF) events', distinguishing it from sibling tools like 'caddis_get_equipment_excessive_downtime' (single event) and 'caddis_list_org_unit_excessive_downtimes' (different 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?
No explicit guidance on when to use this tool versus alternatives. The description only mentions that both start and end are required, but does not compare with siblings like 'caddis_get_equipment_excessive_downtime' or provide context for selection.
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?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds no behavioral traits beyond these, such as pagination behavior, error conditions, or performance considerations. The detailed TOON format explanation is about response structure, not behavior per se.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, but the extensive TOON encoding explanation (including example and detailed rules) makes it lengthy. While the format is non-standard and warrants explanation, the example is generic and could be shortened or made tool-specific.
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 lacks a tool-specific response structure example. The provided TOON example appears to describe a company object with equipment arrays, not a list of devices. This misalignment leaves the actual response format ambiguous. No output schema exists to compensate, so more specific guidance is needed.
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?
No parameters exist (input schema is empty, schema coverage 100%). Per guidelines, baseline score for 0 parameters is 4. The description correctly does not add parameter info, as 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 it lists all physical Caddis devices with their assigned equipment. The verb 'list' and the specific resource 'physical Caddis devices' make the purpose unambiguous. It naturally distinguishes from sibling like caddis_get_device (singular) and other listing tools.
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 versus alternatives (e.g., caddis_get_device for a specific device, or caddis_list_equipment for equipment-only lists). The description does not mention prerequisites, limitations, or context where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the unusual TOON encoding format, which is a behavioral trait, but does not disclose other aspects like pagination, performance, or error handling. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, but the extensive TOON format explanation makes it verbose. While thorough, it could be more concise or moved to a separate specification. Every sentence earns its place but overall length reduces conciseness.
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 no output schema, the description explains the return format in detail, which is good. However, it lacks information about potential result size, pagination, or error states. Annotations indicate open-world behavior but no specifics are provided, leaving some gaps for a complete 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?
There are no parameters, so the schema provides full coverage. The description adds no parameter information, but baseline for zero parameters is 4, as no additional semantic value is 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 clearly states the tool lists equipment visible to the authenticated user in the active company, including current status. This provides a specific verb and resource, but does not explicitly differentiate from sibling list tools like caddis_list_devices.
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, nor any exclusions or prerequisites. The description focuses solely on what the tool does and the response format, leaving the agent to infer usage context.
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?
Discloses that responses are TOON-encoded with detailed format explanation. Annotations already indicate read-only and idempotent behavior; description adds value on response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the TOON encoding explanation is excessively long for a simple list tool, harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of the actual response fields (e.g., id, name, active). The format explanation is detailed but incomplete without specifying which properties are returned.
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?
Parameters are fully described in schema (100% coverage). Description only restates the filters without adding new meaning.
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?
Clearly states 'List cycle tags for the company' with optional filters. Differentiates from siblings like caddis_get_tag but does not explicitly contrast with other list 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?
No explicit when/when-not guidance. Usage is implicitly clear from the name and description, but no alternatives suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to cover these. However, it adds valuable behavioral context by detailing the TOON-encoded response format, which is non-standard and essential for correct interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but then spends a significant portion explaining the TOON format. While necessary, it is lengthy and could potentially overwhelm the agent. Still, it is well-structured with examples.
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?
Despite lacking an output schema, the description thoroughly explains the TOON response format, providing examples and edge cases. It does not cover error conditions or authentication, but for a simple read operation this is acceptable.
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 for the single parameter (deviceId) is 100%, with a clear description in the schema. The tool description adds no additional semantic meaning beyond what the schema already provides, so baseline 3 applies.
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 'Fetch a single Caddis device by ID, including its attached equipment.' This is specific and informative, but it does not differentiate from sibling tools such as caddis_get_equipment, which may also fetch a single item.
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 vs. alternatives like caddis_list_devices or caddis_get_equipment. The description focuses solely on the response format, leaving the agent without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds value by detailing the response format (TOON) and the data included (schedule, inheritance, timezone), which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to a detailed tutorial on the TOON format. While informative, it is not concise for an AI agent, and much of the content could be abbreviated or moved to documentation.
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?
No output schema exists, so the description must fully explain the response. It does so with a clear example and detailed format rules, ensuring the agent can parse and understand the output.
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 100% for the single parameter equipId, which is already described as numeric identifier. The description adds nothing beyond the schema, so baseline 3 applies.
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 returns the current schedule for a piece of equipment, including inheritance and timezone. This is specific and distinguishes it from sibling tools like get_equipment or get_org_unit_schedule.
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 versus alternatives such as get_org_unit_schedule. The description lacks usage context, prerequisites, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds value by detailing the TOON-encoded response format and default behavior (interval, timezone). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose but then includes a lengthy, detailed explanation of the TOON-encoded response format, which could be condensed or linked externally. It is informative but not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return format and defaults. It covers essential behavioral aspects, though it omits error handling or date range limits, which is acceptable for a read-only tool.
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 100%, and the description repeats defaults already present (interval '1d', timezone 'UTC'). It does not add new parameter meaning beyond what the schema provides.
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 it provides 'Grouped utilization metrics for a piece of equipment' and details the bucketing of running/down seconds, making the tool's function clear and distinct from siblings like caddis_get_equipment or caddis_get_equipment_schedule.
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 such as caddis_get_equipment_cycles or caddis_get_org_unit_utilization. There are no explicit when-to-use or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context on the TOON encoding format for response interpretation, which is a non-obvious behavioral trait. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to the detailed TOON format explanation. While necessary for understanding the response, it could be more concise. The structure is clear: first line states purpose, then format details.
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?
No output schema is provided, so the description must explain return values. It explains TOON formatting with a generic example, but does not specify the fields specific to excessive downtime events (e.g., duration, reason). This leaves ambiguity about the actual response structure.
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 100%; each parameter has a description. The description does not add new information beyond the schema, merely stating that start and end are required. Baseline score of 3 is appropriate.
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?
Title and description clearly state the tool lists excessive downtime events across equipment under an org unit within a closed time window. It distinguishes from sibling tools like caddis_list_equipment_excessive_downtimes (per equipment) and caddis_get_org_unit (org unit details).
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 org-unit-level downtime data but lacks explicit guidance on when to use this tool vs. alternatives like caddis_list_equipment_excessive_downtimes. No 'when not' or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds substantial context about the TOON-encoded response format with a detailed example, which is critical since there is no output schema. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose but then includes a lengthy TOON encoding explanation and example. While informative, it could be condensed. The encoding details are necessary given no output schema, but they make the description verbose.
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 description covers the query constraints and output format thoroughly, but it does not specify the exact fields returned for shift boundaries (e.g., scheduled start/end, worked start/end). The example is about equipment, not shift history. Pagination or limits are not mentioned.
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 100% with good descriptions. The description adds the concept of a 'closed-window query' but does not provide new details beyond what the schema already states. Baseline 3 is appropriate.
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 retrieves historical shift boundaries (start/end, scheduled/worked) for a piece of equipment, with specific verb+resource. It also distinguishes itself from sibling tools like caddis_get_equipment_schedule by focusing on shift boundaries and requiring a closed window.
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 explicitly states 'Both start and end are required — this is a closed-window query,' which tells the agent to provide both parameters. However, it does not provide guidance on when not to use this tool or compare it to alternatives like caddis_get_equipment_schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint, idempotentHint, openWorldHint. The description adds value by detailing the TOON-encoded response format with examples, which is not covered by annotations. However, it does not mention error responses or authentication, but the annotations cover the key behavioral traits.
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 well-structured: first sentence defines purpose, then example with clear formatting rules. The TOON explanation is necessary for parsing the response. It is slightly lengthy but every sentence adds value; could be trimmed but still effective.
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 no output schema, the description fully explains the response format with examples and rules. All necessary context for invoking the tool and interpreting results is provided, including parameter requirement and status field.
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 only parameter, equipId, is fully described in the schema (type, format). The description adds no additional semantics beyond 'Fetch by ID', which is already clear from the tool name. With 100% schema coverage, baseline is 3.
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 'Fetch a single equipment record by its ID,' which is a specific verb-resource pair. It is distinct from siblings like caddis_list_equipment (lists all) and other get tools for specific data.
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 any guidance on when to use this tool versus alternatives (e.g., list_equipment for multiple records, or other get tools for different data). No explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world behavior. The description adds details on timezone handling, interval bucketing, and response format (TOON encoding), providing additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose but includes a lengthy explanation of the TOON encoding format. While necessary due to non-standard output, it reduces conciseness.
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 no output schema, the description thoroughly explains the result format and aggregation logic. It covers defaults but does not mention pagination or query limits, leaving minor gaps.
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?
Input schema descriptions cover 100% of parameters. The description mentions default values for 'interval' and 'tz' but does not add further semantic meaning beyond what schema already provides.
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 aggregates utilization metrics for all equipment under an org unit, with bucketing into intervals. This differentiates it from sibling tool 'caddis_get_equipment_utilization' which is per-equipment.
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 does not explicitly state when to use this tool versus alternatives like 'caddis_get_equipment_utilization'. Usage context is implied by the name and description but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds significant value by explaining the TOON-encoded response format with a detailed example and rules. This helps the agent interpret the output, going beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, but the extensive TOON format explanation makes it verbose. While informative, it could be more concise by referencing external documentation. Every sentence is earned, but overall length is disproportionate for a simple fetch tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and read-only annotations, the description covers the purpose, parameter, and response format comprehensively. It lacks only potential error conditions or null scenarios, which are minor for this use case.
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 100% with one parameter (tagId) already described in the schema. The description does not add further meaning or usage context for the parameter, so baseline score of 3 applies.
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 title 'Get one cycle tag' and description 'Fetch a single cycle tag by ID' clearly state the tool's action and resource. It distinguishes from siblings like caddis_list_tags (lists all tags) and caddis_get_tag_group (gets a group).
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 does not explicitly state when to use this tool versus alternatives, nor provide conditions or exclusions. The usage is implied by the naming, but no guidance is given for an AI agent to decide between this and other tag-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open world. The description adds important behavioral context by thoroughly explaining the TOON encoding format of the response, which is critical for interpreting results. It also mentions that records include operator-assigned reason if available.
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 front-loaded with the purpose, then provides a detailed but necessary explanation of the TOON response format. While lengthy, the content is not wasted; it is essential for understanding the response. However, it could be slightly more concise in the format explanation section.
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?
Despite the lack of an output schema, the description thoroughly explains the response format with examples, making the response comprehensible. It covers the purpose and identification of records. It does not address error scenarios but is otherwise complete for a single-record fetch tool with safe annotations.
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 already provides descriptions for all three parameters, and the tool description does not add any new semantic information about the parameters beyond what is in the schema. The description implicitly explains that the parameters together identify the record, but this is clear from the parameter names and 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 it fetches a single excessive downtime record identified by shift history and status log pair for equipment. This is specific and distinct from the sibling list tool.
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 does not explicitly guide when to use this tool versus the list tool or other get tools. It is implied that one should use this when they have the specific IDs, but no when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds significant behavioral context by detailing the TOON-encoded response format, which is crucial for correct parsing. This goes beyond the annotations and provides practical usage guidance.
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 front-loaded with the core purpose, then provides a detailed but necessary explanation of the TOON format. While lengthy, every sentence adds value for correct usage. Could be slightly more concise, but overall well-structured.
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 1 required parameter, full schema coverage, good annotations, and no output schema, the description is largely complete. It explains the response format thoroughly and implies the return of equipment data. Lacks mention of potential errors or limits, but those are minor given the simplicity.
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 100%, and the schema already documents runId as accepting string or number. The description only says 'by ID' and adds no new semantic details beyond what the schema provides. Baseline 3 is appropriate.
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 'Fetch a single production run by ID, including its equipment.' The verb 'fetch' and resource 'production run' are specific, and the scope (single by ID) distinguishes it from siblings like caddis_list_runs or caddis_get_run_cycles.
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 a single run by ID, but it doesn't provide explicit when-to-use or when-not-to-use guidance against sibling tools. It lacks alternatives or exclusion criteria, though the purpose is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds substantial value by explaining the non-standard TOON response format in detail, which is critical for correct usage. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in the first sentence. The extensive TOON encoding explanation, while long, is structured with bullet points and justified by the non-standard format. Slightly verbose but acceptable.
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 complex response format and absence of an output schema, the description provides a thorough explanation of the TOON encoding, including examples and edge cases. This makes the tool complete for an agent to interpret responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% and already explains that tagGroupId accepts string or number forms. The description adds no further parameter information, so baseline 3 is appropriate.
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 'Fetch a single tag group by ID', using a specific verb and resource. It distinguishes this tool from siblings like caddis_list_tag_groups (which retrieves all) and caddis_get_tag (which gets a tag, not a group).
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 fetching a single tag group by ID but does not explicitly state when to use or not use this tool, nor does it reference alternatives. The context is clear but lacking explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, openWorldHint), the description adds parallel dispatch, retry/dedup preservation, failure isolation ('One failed request does not sink the batch'), and response format (prefix per request).
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 relatively concise, front-loaded with core purpose, and lists available tools as an unordered set. While the tool list is lengthy, it is necessary for clarity.
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 batch tool with no output schema, the description covers input, behavior (parallelism, limits, error handling), and response format (prefixed text blocks). No obvious gaps.
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 100% coverage on the 'requests' parameter; the description adds behavioral context but does not add semantic meaning beyond the schema's description.
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 'Run multiple caddis_* tools in a single call, fanning out in parallel' with a specific verb and resource, and lists all available tools, distinguishing it from individual 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions limits (up to 20 requests, concurrency capped at 1) and preserved retry behavior but lacks explicit when-to-use or when-not-to-use guidance versus individual calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, indicating safe, non-deterministic, idempotent behavior. The description adds value by detailing the TOON-encoded response format, which is essential for parsing the output since no output schema exists.
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 front-loaded with the purpose sentence. The remaining content on TOON encoding is lengthy but structurally well-organized with bullet points and examples. It earns its place by compensating for the missing output schema.
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 no output schema, the description fully explains the response format with examples and edge cases. Combined with annotations, it provides complete context for the agent to invoke and parse the tool correctly.
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 schema coverage is 100% (trivially). Baseline for 0 parameters is 4. The description does not add parameter information, but none is 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 starts with 'List all cycle tag groups for the company,' which clearly states the verb (list) and resource (tag groups). It distinguishes from siblings like caddis_list_tags (lists tags) and caddis_get_tag_group (gets a single group), making the scope 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 for listing all tag groups, but it does not explicitly state when to use this tool versus alternatives like caddis_get_tag_group for a specific group or caddis_list_tags for tags. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds significant value by detailing the TOON-encoded response format with examples and parsing rules, which is crucial for correct invocation. It also advises on limit parameter to avoid large responses. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then provides a comprehensive TOON format explanation. While lengthy, the format details are necessary for tool use without an output schema. Could be slightly more concise but well-structured with examples.
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?
No output schema exists, so description compensates by explaining response format in depth. Covers time-window filtering, status changes, and cross-referencing with statusreasons. Doesn't address error cases or authentication, but those are standard. Overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds marginal value: it refers to 'statusreasons' for decoding but doesn't add parameter-level detail. The limit parameter advice is present in schema already. Adequate but not above baseline.
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 'Running/down status log transitions for a piece of equipment within a time window' identifying the specific verb (get) and resource (status logs). It distinguishes itself from sibling tools like caddis_get_equipment_utilization or caddis_get_equipment_cycles by focusing on status transitions.
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 usage context: 'pair with statusreasons to decode reason IDs' hints at a related tool, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. The tool name and context signals make purpose clear, so no misleading info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent. Description adds vital behavioral context: chatty nature, TOON encoding format with detailed examples. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with warning and purpose, but then a large block of encoding specification (which is necessary for understanding output). Could be more concise, but structure is logical.
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?
No output schema, so description fully compensates by explaining the TOON encoding format with examples. Covers output structure comprehensively. Annotations provide safety context. Complete for a data retrieval tool.
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 100%, so baseline is 3. Description echoes 'tight window and limit' but adds no new semantic meaning beyond 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?
Clearly states 'Raw telemetry data points for a piece of equipment within a time window.' Specific verb+resource: 'get' + 'telemetry'. Easily distinguished from siblings like utilization, schedule, cycles, statuslogs.
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?
Explicitly warns 'Very chatty — always scope with a tight window and limit.' Provides clear usage context. Does not explicitly name alternative tools for non-telemetry needs, but that's acceptable given sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral context about response format (TOON-encoded) and what data is returned (direct equipment and child org units), though it does not detail authentication or rate limits. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and alternative, but then includes an extensive, verbose explanation of the TOON encoding format with examples. This reduces conciseness, as the format details could be more compact or placed elsewhere.
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 has one parameter, no output schema, and annotations, the description fully covers what the tool does, what it returns, and how to parse the response. It also distinguishes from sibling tools, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already describes 'orgUnitId' as a numeric identifier. The description does not add any new information about parameters, so it meets the baseline for high 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 clearly states 'Fetch a single organizational unit with its direct equipment and child org units,' which is a specific verb (fetch) and resource (org unit). It distinguishes from sibling 'caddis_get_tree' by noting that alternative is for the whole tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use (fetch one org unit) and when-not-to-use ('For the whole tree, use caddis_get_tree instead'), offering a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds valuable behavioral details: response format (TOON-encoded) with a comprehensive example and rules, plus a warning about large responses. This goes well beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states purpose, then a warning, then a detailed but organized explanation of the TOON format with clear bullet points. Every sentence adds value given the non-standard output 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?
The description includes output format and performance guidance, which is critical since no output schema exists. It covers required params and default behavior implicitly through the schema. Minor missing explicit restatement of defaults (limit, order) in the main description, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are already described. The description does not add new semantics beyond mentioning 'time window' and the format, but the schema itself is sufficient. Baseline 3 applies.
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 defines the tool's purpose: 'Production cycles (individual part/unit runs) for a piece of equipment within a time window.' It uses a specific verb ('get' implied) and resource ('equipment cycles'), distinguishing it from sibling tools like schedule or utilization.
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 advises to keep windows and limits modest due to high cycle counts, providing important usage context. However, it does not explicitly compare to siblings like caddis_get_run_cycles or state when to use this tool over others, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations (readOnly, openWorld, idempotent) by detailing the TOON response format, the five tabular sections, join keys, JSON-stringified columns, history cap, and parsing instructions. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but front-loaded with the core purpose and filters, followed by necessary explanation of the non-standard TOON format. Every sentence adds value, though a briefer summary of the format might suffice. Still, it earns a 4 for being well-structured despite length.
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?
With no output schema, the description fully compensates by explaining the TOON response structure, example, join keys, special column handling, and parsing. For a complex tool, this is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description restates the optional filters but adds no new meaning or syntax details beyond what the schema provides. Baseline 3 is appropriate.
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 lists enabled alarms with type definitions, latest history, and subscribers, and offers optional filters by equipment or PM type. This verb+resource statement distinguishes it from sibling list tools like caddis_list_devices or caddis_list_equipment.
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 what the tool does and the optional filters, but does not explicitly state when to use it versus alternatives or when not to use it. Since there is no other alarm-specific list tool, the context is clear enough without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the TOON-encoded response format in detail, including examples and edge cases. This is critical for an agent to correctly parse the output, adding significant value beyond the readOnlyHint and idempotentHint annotations.
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 front-loads the core purpose and filter option, then provides a necessary but lengthy explanation of the response format. While the encoding detail is valuable, it could be condensed slightly without losing clarity, earning a score of 4.
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?
With no output schema, the description fully compensates by detailing the TOON-encoded response format with examples, covering object fields, arrays, nested objects, and special cases. This ensures the agent can interpret results correctly, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter manufacturerId is described adequately in both the schema and the description. Since schema coverage is 100%, the description adds no extra meaning beyond what the schema already provides, earning a baseline score of 3.
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 that the tool lists equipment models for the company, sorted by model number, with optional manufacturer filtering. This distinguishes it from sibling tools like caddis_list_devices and caddis_list_equipment, which list other entity types.
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 when to use this tool (to list models) and mentions the optional filter. However, it does not explicitly state when not to use it or suggest alternatives, which would improve clarity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds value by explaining the TOON-encoded response format in detail, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise for purpose, but the TOON-encoding explanation is lengthy. While necessary, it could be more structured or refer to external documentation.
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 no output schema, the description compensates by fully explaining the custom output format. It covers parameters, purpose, and output, making it 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?
Schema coverage is 100%, baseline 3. The description adds meaning by explaining that start/end define an interval intersecting the run's active interval, which is not in the 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 'List production runs for the company' and mentions optional filters, distinguishing it from siblings like `caddis_get_run` which retrieves a single run.
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?
No explicit when-to-use vs alternatives, but the name and description imply this is for listing multiple runs, while siblings like `caddis_get_run` are for single runs. Clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the non-standard TOON encoding format in extensive detail, including syntax rules, null handling, and quoting. Annotations already declare the tool as readOnly, openWorld, and idempotent. The description adds significant behavioral transparency beyond annotations, fully informing the AI agent of what to expect in the response.
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 front-loaded with purpose and usage, followed by a detailed format explanation. While the format section is lengthy, it is well-structured and every sentence provides value for understanding the response. Slight verbosity keeps it from a 5, but it remains clear and organized.
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?
With no output schema, the description fully explains the return format and structure, including examples. Given the tool's zero parameters, the description covers all necessary context: what it does, when to use it, and how to interpret the response. It is complete for effective use.
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 description cannot add meaning beyond the schema. Per guidelines, baseline is 4. The description does not need to elaborate on parameters since 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 fetches the active company's top-level settings (name, timezone, point-of-contact). This distinguishes it from sibling tools that deal with devices, equipment, runs, etc. The verb 'Fetch' and specific resource 'company' with listed fields make the purpose unambiguous.
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 explicitly recommends using this tool 'as a first call to confirm which company the session is scoped to', providing clear context for when to use it. It does not explicitly mention when not to use it or alternatives, but given the uniqueness of this tool among siblings (no other company-fetching tool), this is not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses that the response is TOON-encoded and provides a detailed example and explanation of the encoding format, adding significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage in the first sentence, but the subsequent extensive TOON format explanation makes it lengthy. While necessary for understanding the unusual output, it could be more concise.
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 read-only tool with a single parameter and no output schema, the description fully explains the response format and encoding, making it complete for an agent to use correctly.
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 100%, so the schema documents the parameter runId. The description adds no extra meaning beyond that, meeting the baseline. No additional parameter details are provided.
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 returns 'all production cycles associated with a specific run,' using a specific verb (get) and resource. It distinguishes from the sibling tool caddis_get_equipment_cycles by specifying the scope as a 'known run.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool ('when the scope is a known run') and when to use the alternative ('caddis_get_equipment_cycles'), providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description fully details the output format (TOON-encoded) with examples and edge cases, effectively compensating for the missing output schema. No contradictions.
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?
Purpose and usage are front-loaded, but the lengthy TOON format explanation adds verbosity. However, it is necessary and well-structured, earning a 4.
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?
Complete for a parameterless tool: covers purpose, usage, and response format in depth, leaving no ambiguity about what the tool returns and how to parse 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?
With 0 parameters, baseline is 4 per guidelines. The description adds no parameter info but schema coverage is 100% (empty schema), so no gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists equipment categories sorted by name and clarifies its use for decoding category of equipment, distinguishing it from sibling tools that list devices or equipment.
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?
Provides a clear use case ('decode the category of a piece of equipment') but does not explicitly mention when not to use or compare with sibling tools like caddis_get_equipment which might also contain category info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds substantial behavioral details: it explains the TOON-encoded response format with examples, clarifies the sorting behavior, and notes that responses are token-efficient. This goes beyond the annotations and helps the agent handle the output correctly.
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 front-loaded with the core purpose and usage, then provides a detailed but necessary explanation of the TOON format. While the format explanation is long, it is essential for correct interpretation. The structure is logical and each sentence serves a purpose.
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 that there are no parameters and the annotations already cover readOnly, openWorld, and idempotent aspects, the description fully compensates by thoroughly documenting the response format (TOON encoding) with an example. No important aspect is missing for an agent to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description cannot add parameter-level detail beyond the schema (which has 100% coverage by stating no properties). The baseline is 4, and the description does not contradict or improve that; it simply provides contextual meaning for the tool's no-parameter interface.
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 manufacturers sorted by name and explicitly says it can be used to decode a manufacturer or look up an ID for caddis_list_models. This establishes a specific verb+resource combination and distinguishes it from sibling list tools that list different entities.
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 explicit use cases ('Use to decode...' and 'look up a manufacturer ID...'), which guides when to use the tool. It does not include when-not-to-use or mention alternatives, but the given context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent. The description adds detailed behavioral context: response is a TOON document, hierarchy is encoded in path columns, and how to reconstruct the tree. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: main purpose first, then parameter behavior, then TOON format explanation with examples. Every sentence is informative; however, the TOON format explanation could be referenced as an external link.
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 no output schema and the complexity of the TOON format, the description is exceptionally complete. It covers the response structure, how to interpret hierarchy, and what data is absent. An example clarifies formatting rules.
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 100% and the parameter is simple. The description explains the semantic effect of providing or omitting orgUnitId (full tree vs subtree). This adds context beyond the schema property description.
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 'Structural overview of the org-unit hierarchy with the equipment and devices under it,' specifying the verb 'get' and the resource 'tree.' It further distinguishes from siblings by listing data not included (schedules, config blobs) and providing alternative tool names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool (structural overview) and the effect of the optional parameter: without orgUnitId returns full tree, with orgUnitId returns subtree. It also lists exactly what is not included and names alternative tools for those needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read operation; description adds critical context about TOON-encoded response format, essential for correct parsing.
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?
Description is front-loaded with purpose and usage, but the detailed format explanation is lengthy. However, it is necessary and well-structured with examples.
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?
Thoroughly explains the return format with examples and decoding instructions, fully compensating for the lack of an 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?
No parameters exist, so schema coverage is 100%. Baseline for 0 params is 4; description adds no parameter info but none is 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?
Clearly states the verb 'list' and resource 'active status reasons' with specific purpose of classifying downtime. Distinguishes from sibling list tools by focusing on status reasons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises combination with caddis_get_equipment_statuslogs to decode reason IDs, providing clear workflow guidance.
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:

[![lcm2m-caddis-mcp MCP server](https://glama.ai/mcp/servers/LCM2M/lcm2m-caddis-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LCM2M/lcm2m-caddis-mcp)

Score Badge

Copy to your README.md:

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

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