level-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., listDevices vs. showDevice vs. updateDevice). No two tools appear to perform the same operation, and even similar actions like tagDevices and removeTagFromDevices are clearly separated. The tool set is well-organized by resource.
Naming Consistency5/5
Tool names follow a consistent verb-noun pattern in camelCase (list, show, create, update, delete, assign, remove, tag, trigger, resolve). Multi-word actions like assignGroupDevices and removeTagFromDevices remain readable and consistent with the pattern.
Tool Count2/5
With 35 tools, the server is above the 25-tool threshold for 'too many'. While the broad scope covers multiple resource types (devices, groups, tags, custom fields, alerts, updates, automations), the sheer number creates a heavy surface that may overwhelm agents. A more focused set would improve usability.
Completeness2/5
The surface has significant gaps: there is no createDevice, and custom field values lack an explicit create operation. Alerts only support list/show/resolve, updates only support list/show, and automations are missing create/update/delete. These omissions will force agents to work around missing core operations, especially for device lifecycle management.
Average 3.4/5 across 35 of 35 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior, but the description adds no further insight into side effects, permissions, or consequences (e.g., whether deletion cascades to tagged devices). The endpoint detail is not behavioral.
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 two sentences are redundant, repeating 'Delete tag' / 'Deletes a tag'. This wastes space and adds no value. The structure is not front-loaded with unique information.
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?
Given the destructive nature, the description should explain what happens to tag-device relationships or any prerequisites. It also does not distinguish from sibling tools like removeTagFromDevices. The lack of an output schema is fine, but the behavioral context is incomplete.
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 covers the single 'id' parameter with a clear description, achieving 100% schema_description_coverage. The tool description adds no extra parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete tag. Deletes a tag.' essentially restates the tool name and title, providing no new information about scope or behavior. The API endpoint line adds a technical reference but does not clarify what the deletion entails (e.g., permanent removal, effect on device associations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related operations such as removeTagFromDevices, which handles detaching tags from devices. The description lacks any contextual or alternative usage directions.
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=false, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond the endpoint. It does not mention admin_only restrictions or any side effects, so it adds little to what annotations already convey.
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 redundant: 'Update custom field. Updates a custom field.' The second sentence is pure repetition, wasting space. It could be reduced to a single effective sentence. This is not concise but rather padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too thin for a tool with multiple siblings. It lacks any guidance on what the update entails, the distinction from value updates, or prerequisites. The endpoint info is minor and does not compensate for the missing context.
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%, with each parameter having a clear description. The tool description adds no parameter info, but the schema already fully documents 'id', 'name', and 'admin_only'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: 'Update custom field. Updates a custom field.' It restates the title without adding any specificity. It does not distinguish this tool from the sibling updateCustomFieldValue, which is a related yet different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like updateCustomFieldValue or createCustomField. The description only mentions the API endpoint, which does not help an agent choose among sibling tools.
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 provide idempotentHint and destructiveHint, so the description does not need to repeat those. However, it adds only the API endpoint, which is not a behavioral trait. There is no mention of side effects, permissions, or response behavior, so it contributes little 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the first two sentences are redundant tautologies ('Update device. Updates the specified device.'). The endpoint line is useful, but the repetition wastes space and makes the structure less efficient than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description should provide more context about what updates are possible, behavior of group_id null, or what the response contains. It lacks this information, making it incomplete for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any meaning to the parameters beyond what is already in the schema. With 75% schema coverage, the schema already documents the parameters, and the description merely says 'updates the specified device' without explaining how name, notes, or group_id are used.
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 clearly states the tool updates a device and includes the API endpoint PATCH /v2/devices/{id}, which identifies the verb and resource. However, it largely repeats the title and does not specify what aspects of the device can be updated, making it less informative than it could be.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like assignGroupDevices or updateCustomFieldValue. The description simply restates the action without providing context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral details beyond the fact that a group is created. Annotations already indicate it's not read-only (readOnlyHint: false), but the description doesn't disclose effects like how parent_id influences creation, potential uniqueness constraints, or any side effects. The API endpoint is a technical detail, not a behavioral trait.
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 very short, which is good, but it contains clear redundancy: 'Create group' and 'Creates a new group' say the same thing. The phrase 'Level API endpoint' is awkward and unclear. It could be more concise and structured by removing duplication and explaining the endpoint clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with two parameters, the description is minimal and does not contextualize the tool within the broader API. It doesn't explain what a group is, what creating one implies, or how the parent_id parameter affects the outcome. The schema provides some parameter details, but the description itself is inadequate for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the schema. With schema coverage at 50% (and the description not compensating), the agent gets no additional context about how to fill parameters or what behaviors they trigger. The parent_id semantics are left entirely to the schema.
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 clearly states the action (create) and the resource (group), but 'Create group' and 'Creates a new group' are redundant and essentially restate the tool name. The API endpoint 'POST /v2/groups' adds some specificity, but there is no meaningful differentiation from sibling tools other than the resource name.
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 about when to use this tool versus alternatives. It does not mention prerequisites, use cases, or exclusions. The usage is only implied by the name and basic action, which is insufficient for an agent deciding between this and other create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, but the description does not explain effects like moving groups via parent_id or that updates are partial.
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 short but somewhat redundant ('Update group. Updates an existing group.'). It is front-loaded and not bloated, but the first sentence merely repeats the title, wasting a small opportunity for more useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description is minimal but lacks important context such as the optional nature of name and parent_id, the semantic of parent_id moving a group, or any note about partial updates. It relies heavily on the schema and does not fully compensate for the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters, relying entirely on the input schema. Schema description coverage is 67%, which is moderate but not high enough to offset the lack of supplementary parameter guidance in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update group' and 'Updates an existing group,' identifying the action and resource. It is distinguishable from sibling tools like createGroup and deleteGroup, though it adds little specific detail about what can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as createGroup or showGroup. It neither states prerequisites nor exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not mention side effects, required permissions, idempotency implications, or what happens on success. The endpoint detail is minor and does not clarify behavioral traits. Annotations already indicate readOnlyHint=false, but the description fails to elaborate on the write nature.
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 wastes words by repeating the same idea: 'Create custom field. Creates a custom field.' This redundancy makes it less concise. A single sentence with the endpoint would be sufficient.
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?
Despite having annotations and complete parameter descriptions, the description is too thin. For a create operation with no output schema, it should at least hint at the response (e.g., returns the created field) or mention any side effects. The missing return value information and lack of behavioral context make it incomplete.
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 both parameters ('name' and 'admin_only') having descriptions. The tool description adds no parameter-specific information, so the baseline of 3 applies. No extra meaning is provided beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and resource 'custom field', which distinguishes it from sibling tools like updateCustomField, listCustomFields, and deleteCustomField. The endpoint reference adds specificity, but the repetition of 'Create custom field' and 'Creates a custom field' is redundant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as updateCustomField or deleteCustomField. The description only states the action without any context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds only the HTTP endpoint, which is not relevant behavioral context for an AI agent, and does not disclose pagination behavior or filtering beyond what the schema provides.
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 short but redundant: 'List tags' and 'Returns a list of tags' are essentially the same statement. The inclusion of the REST endpoint adds unnecessary technical detail not useful for tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, good annotations, and complete parameter schema, the description is just minimally complete. It states that a list of tags is returned, but does not mention the optional device_id filter or pagination, though these are covered in the schema.
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%, with all 4 parameters (limit, device_id, ending_before, starting_after) clearly documented in the input schema. The description adds no parameter details, so it does not exceed the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tags and returns a list of tags, using the specific verb 'list' with the resource 'tags'. It distinguishes from siblings like createTag/updateTag/deleteTag/showTag, though it does not explicitly mention these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as showTag for retrieving a single tag. It only states the basic action without any context on appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds only the endpoint 'POST /v2/tags', which is a technical detail but not behavioral context such as duplicate handling, return values, or side effects. Given the openWorldHint is true, more disclosure would be valuable.
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 short but repeats itself: 'Create tag' and 'Creates a new tag' are redundant. The endpoint line adds useful technical info. It is not overly verbose, but not every sentence earns its place due to the duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter creation tool, the description is minimally viable. It lacks any mention of return values, error conditions, or side effects, but the absence of an output schema and the low complexity keep it adequate. More context about duplicate tags or permissions would improve completeness.
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 covers 100% of the single parameter 'name' with the description 'The tag name.' The tool description does not add any additional parameter semantics beyond the schema. Since schema coverage is complete, the baseline of 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 the action and resource: 'Create tag. Creates a new tag.' The verb 'create' and resource 'tag' accurately distinguish this from sibling tools like updateTag or deleteTag. However, it is somewhat redundant and lacks additional scope differentiation (e.g., what kind of tag), so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when to prefer createTag over other tag-related operations like tagDevices or updateTag, or any exclusions. The description only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate non-read-only, non-idempotent, and open-world behavior, but the description adds nothing beyond the API endpoint. It does not disclose potential side effects, authentication requirements, or what happens when a tag is applied to an already-tagged device. The openWorldHint=true is not explained.
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 extremely short, but the first two sentences ('Tag devices' and 'Applies a tag to the provided devices') are redundant. The API endpoint is a useful addition. Slight redundancy prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description is adequate for basic invocation. However, it lacks information about side effects, response, or how it contrasts with removeTagFromDevices, which is relevant given the sibling context. A bit more context would improve completeness.
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 fully describes both parameters (id and device_ids) with clear descriptions, and the description adds no additional semantic value. Per the baseline for high schema coverage, this scores a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Tag devices') and the object ('the provided devices'), making the tool's purpose immediately recognizable. However, it does not explicitly differentiate from sibling tools like removeTagFromDevices, though the opposite nature is implicit. The API endpoint adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as removeTagFromDevices or listTags. It simply states what it does, leaving the agent to infer usage context. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. It reveals the HTTP POST endpoint, which is consistent with the readOnlyHint=false, but does not disclose handling of existing assignments, idempotency, error behavior, or side effects. The openWorldHint=true suggests additional side effects, but nothing is explained.
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 short but repetitive: the first two sentences restate the same idea, and only the endpoint adds new information. It is not excessively long, but the redundancy wastes words that could have been used for context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema and available annotations, the description is adequate for a basic understanding. However, it lacks any mention of response format, edge cases, or relationship to other group/device tools, so it is not fully complete for an agent making informed decisions.
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 covers both parameters with clear descriptions (group ID and array of device IDs). The description adds no extra parameter semantics or usage details, so the baseline of 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: assigning devices to a group. It specifies the resource (devices) and target (group), and the endpoint further clarifies the operation. It distinguishes from sibling tools like removeGroupDevices by focusing on assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention the inverse operation (removeGroupDevices) or any conditions, prerequisites, or exclusions. Usage is implied only by the tool's name and title.
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 destructive and idempotent behavior, but the description adds only the API endpoint, not consequences like cascade effects or irreversibility. There is no explanation of openWorldHint implications, so transparency is limited.
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 two sentences are redundant ('Delete custom field' and 'Deletes a custom field'), violating the principle that every sentence should earn its place. The endpoint sentence adds value but does not compensate for the tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation, the description is minimal. It does not mention what happens to associated values, whether deletion is permanent, or any prerequisites. The openWorldHint and destructiveHint are present but not explained in context.
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 fully describes the 'id' parameter with 100% coverage, so the description is not required to add parameter details. No additional semantic value is provided beyond the 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?
Clearly states the operation (delete) and the target resource (custom field), reinforced by the HTTP DELETE endpoint. Distinguishes from sibling delete tools like deleteDevice and deleteTag by naming the resource.
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 name and endpoint imply the tool is for deleting custom fields, but no explicit when-to-use guidance or alternatives are provided. Siblings like deleteCustomFieldValue and updateCustomField exist, but the description does not help choose between them.
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 indicate this is a write operation (readOnlyHint: false), idempotent (idempotentHint: true), and non-destructive (destructiveHint: false). The description adds only the HTTP endpoint (PATCH /v2/tags/{id}), which hints at partial update semantics, but it does not disclose error behavior, auth requirements, or the return value. 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 is short but contains redundancy: 'Update tag.' and 'Updates an existing tag.' say nearly the same thing. The phrase 'Level API endpoint' is cryptic and may confuse rather than help, detracting from the otherwise minimal structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with full schema coverage and existing annotations, the description is passable but thin. It doesn't explicitly state that this is a partial update (PATCH) or that only the 'name' field can be changed, which would be valuable context. Missing an explanation of the endpoint's 'Level' qualifier adds 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?
The schema has 100% coverage with clear descriptions for both 'id' and 'name', so the baseline is 3. The description does not add any parameter-specific guidance beyond the schema, such as noting that 'name' is optional for partial updates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Updates an existing tag,' which clearly identifies the verb (update) and resource (tag), distinguishing it from create or delete operations. However, it doesn't name the specific updatable field (name) beyond what the schema provides, and the first sentence simply mirrors the tool title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like createTag or deleteTag. It does not mention that this should be used only for existing tags or that to change a tag's name you use this tool. No exclusions or alternative tool mentions.
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=true and destructiveHint=false, so the read-only nature is covered. The description adds the API endpoint but does not disclose additional behaviors like pagination defaults, authentication requirements, or rate limits. 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 short and front-loaded with the core action, but the first two phrases 'List custom fields' and 'Returns a list of custom fields' are redundant. The endpoint is useful but could be integrated more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, annotations, and complete schema, the description is minimally adequate but lacks any mention of return structure or when to combine with pagination parameters. It does not explain what a 'custom field' contains or how the result is ordered, leaving some ambiguity for an 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%, with all three parameters (limit, ending_before, starting_after) already documented in detail. The tool description adds no additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'custom fields', and provides the API endpoint GET /v2/custom-fields. It distinguishes from sibling tools like listCustomFieldValues by focusing on the custom field objects themselves, though it does not explicitly call out alternatives.
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 related tools such as listCustomFieldValues or showCustomField. The description only provides the endpoint, leaving the agent to infer context from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the list is user-specific ('your updates'), a scoping detail not present in the annotations. However, it omits pagination behavior, rate limits, and return structure. Annotations already cover read-only, idempotent, and non-destructive aspects, so this partial disclosure earns a mid-range score.
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 short and front-loaded with the primary purpose. The 'Level API endpoint: GET /v2/updates' sentence is somewhat cryptic and adds little operational value for an agent, but aside from that, there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not mention default behavior like limit=20 or what an update object contains. However, the schema covers all filters and annotations establish safety, making it minimally viable for a straightforward list operation.
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?
All 6 parameters are fully described in the input schema (100% coverage), including filters and pagination cursors. The description adds no additional parameter-level meaning, so it falls at the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists updates and returns the caller's updates. The resource (updates) is distinct from sibling list tools (devices, groups, tags), avoiding confusion. However, it is terse and largely restates the title without adding scope or filtering nuance.
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 listUpdates versus showUpdate or other list tools. There are no alternatives, exclusions, or prerequisites mentioned, leaving the agent to infer usage purely from the resource name.
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=false, destructiveHint=true, and idempotentHint=true, covering the safety profile. The description adds the endpoint URL and clarifies that the action removes the tag from provided devices, implying the tag itself is not deleted. However, it does not elaborate on side effects or authorization requirements, which would be useful 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repetitive. The first sentence ('Remove tag from devices') essentially repeats the title, and the second sentence adds minimal new information. The endpoint line is useful but could be integrated more concisely. Overall, it is structured clearly but not exceptionally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema) and the presence of annotations covering idempotency and destructiveness, the description is mostly adequate. However, it could be more complete by explicitly stating that the tag itself is not deleted and possibly mentioning that repeated calls are idempotent, though the latter is covered by the idempotentHint annotation.
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%: both parameters ('id' and 'device_ids') have clear descriptions. The tool description adds no extra parameter-level semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: removing a tag from specific devices. It effectively conveys the action on a resource ('tag from devices'), and the scope is distinct from sibling operations like 'deleteTag' (which deletes the entire tag) and 'tagDevices' (which adds tags). However, it does not explicitly name these alternatives to differentiate itself.
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 when to use this tool—when you want to remove a tag from certain devices—but it does not provide explicit guidance on alternatives, such as 'deleteTag' for deleting the tag entirely or 'tagDevices' for the inverse operation. No exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds the scope (organization, group, or device) and the API endpoint, but does not disclose potential side effects like cascading deletions when 'force' is used. It adds some context beyond annotations but remains minimal.
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 short but the first sentence 'Delete custom field value' is redundant with the title. The remaining two sentences provide useful scope and endpoint information, but the redundancy slightly 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?
The description gives the scope and endpoint, but does not explain behavior such as what happens with descendants or the effect of 'force'. Since the schema covers parameters, this is acceptable for a delete operation, but it could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters beyond mentioning 'organization, group, or device', which overlaps with the assigned_to_id schema description. The schema already covers the parameters well, so the description adds little semantic value.
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 deletes a custom field value for an organization, group, or device. The verb 'deletes' and the resource 'custom field value' are specific, and the scope distinguishes it from other tools like deleteCustomField (which deletes the field itself).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to delete a specific custom field value at various scopes, but it does not explicitly mention when to use it versus alternatives such as updateCustomFieldValue or deleteCustomField. There is no guidance on when to use the 'force' parameter or exclude certain cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already disclose destructiveHint=true and readOnlyHint=false, which cover the safety profile. The description adds only the API endpoint and restates the delete action; it does not disclose additional behavioral traits such as whether deletion is permanent, whether associated data is removed, or any authorization requirements. Thus, it adds minimal 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 short, but it contains redundancy: 'Delete device.' and 'Deletes the specified device.' say essentially the same thing. The third sentence about the API endpoint is useful. The redundancy means not every sentence earns its place, but the overall structure is not overly verbose.
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 delete operation with one parameter, no output schema, and clear annotations, the description is sufficiently complete. It states the action, the target resource, and the endpoint. The lack of additional details (e.g., response format, side effects) is less critical given the low complexity and the guidance from annotations and schema.
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 covers the single parameter 'id' with a clear description ('The ID of the device to delete'), achieving 100% schema coverage. The tool description does not add further parameter semantics beyond what the schema already provides. Given the high schema coverage, a 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?
The description clearly states the tool's purpose with a specific verb and resource: 'Delete device. Deletes the specified device.' It also provides the API endpoint, adding precision. This distinguishes it from sibling tools like deleteGroup or deleteTag by explicitly naming the device resource.
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 context by naming the action 'delete' and the resource 'device', but it does not explicitly state when to use this tool versus alternatives (e.g., updateDevice or removeGroupDevices). There are no explicit when/when-not guidelines or alternative recommendations, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations. It mentions the endpoint and a return list, but does not disclose pagination behavior, filtering limitations, or other runtime traits. The annotations already cover read-only and idempotent safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences and front-loads the core purpose. The endpoint reference is minimal and not redundant.
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 list tool with rich schema descriptions and safety annotations, the description is minimally adequate. It lacks explicit mention of pagination or return format, but the schema covers parameters. Given no output schema, the description could be slightly more informative, but it is not incomplete 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?
The input schema fully documents all five parameters with descriptions and examples, so the description does not need to add parameter details. It adds no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'alerts' and states 'Returns a list of your alerts,' clearly identifying the tool's function. It is distinct from siblings like showAlert (single alert) and resolveAlert (mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as showAlert or resolveAlert. The description only states what it does, not when to choose it or when to avoid it.
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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the specific endpoint (GET /v2/automation-runs/{id}) and clarifies it retrieves status, but it does not explain response format, pagination, or other behavioral details beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the tool's purpose and immediately adds the endpoint and status retrieval, making it extremely concise and efficient.
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 read-only tool with rich annotations and full schema coverage, the description is adequate. It explains the primary purpose and gives the endpoint, but it could optionally mention what the returned status includes or that include_steps affects output. However, since there is no output schema, the description still provides enough context for an agent to invoke it 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?
The input schema covers 100% of parameters with descriptions for id and include_steps, so the baseline is 3. The description does not add any parameter semantics beyond the schema, but it also does not need to since the schema is self-explanatory.
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 retrieves the status of an existing automation run, using a specific verb and resource. It distinguishes itself from listAutomations by focusing on a single existing run, but it does not explicitly name alternatives or contrast with sibling show/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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like listAutomations. The description only says it retrieves an existing run, which implies it requires a known ID, but it does not state exclusions or alternatives.
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 destructiveHint, covering the safety profile. The description adds the endpoint and 'your groups' scope but does not disclose response format, pagination behavior, or potential limitations. 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 brief and front-loaded, but the first two phrases ('List groups' and 'Returns a list of your groups') are redundant. The endpoint adds value, but the redundancy prevents a perfect score.
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 list operation with fully described parameters and rich annotations, the description covers essentials. It lacks usage guidance but the tool is straightforward. Without an output schema, the description does not need to explain return values, so completeness is adequate.
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 thorough parameter descriptions for limit, parent_id, and pagination cursors. The description does not add any extra meaning beyond what the schema already provides, 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 the tool lists groups, using a specific verb and resource. The endpoint 'GET /v2/groups' reinforces the action. It distinguishes from siblings like showGroup by using 'list' versus 'show'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like showGroup or createGroup. It does not mention pagination, filtering via parent_id, or context for choosing this list operation over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, covering the safety profile. The description adds the HTTP DELETE endpoint, which is mildly informative, but it does not disclose additional behavioral details such as whether non-existent device IDs are ignored or that devices are only removed from the group and not deleted. It does not contradict 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Remove devices from group' and 'Removes the specified devices from the group' say essentially the same thing. The endpoint line is useful. The redundancy prevents a higher score, but it is not overly 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?
For a simple two-parameter tool with good annotations and full schema coverage, the description is minimally adequate. It does not explain return values (though no output schema exists) and does not clarify side effects or edge cases. Overall, it meets the minimum viability but leaves gaps in usage context.
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%: both 'id' and 'device_ids' have clear descriptions in the input schema. The tool description adds no additional parameter semantics beyond what the schema already provides, so the 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 description clearly states the action: 'Remove devices from group' with the verb 'remove' and the specific resource 'devices from a group'. It distinguishes itself from siblings like 'deleteDevice' (which deletes a device entirely) and 'assignGroupDevices' (the opposite operation). The HTTP endpoint adds further specificity.
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?
Usage is implied by the action: if you want to remove devices from a group, this is the tool. However, there is no explicit guidance on when to use it instead of alternatives, no prerequisites, and no mention of consequences (e.g., devices are not deleted). The description does not reference sibling tools or provide exclusions.
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=true and destructiveHint=false, so the safety profile is established. The description adds the endpoint 'GET /v2/devices,' confirming a read operation, but does not disclose additional behavioral traits such as pagination behavior, response structure, or any access requirements. It neither contradicts nor significantly enriches 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short sentences and an endpoint reference. 'List devices' and 'Returns a list of your devices' are slightly redundant, but the overall structure is efficient and front-loaded. It earns a high score for minimal waste, though the redundancy prevents a perfect 5.
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 having no output schema and 15 parameters, the description covers the basic purpose and return value ('Returns a list of your devices'). The schema handles parameter documentation comprehensively. However, it omits context like pagination behavior or filtering scope, which are inferable from the schema but not explicitly stated, leaving room for improvement.
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 input schema fully documents all 15 parameters and their meanings. The description adds no parameter-specific information beyond what the schema provides, making the baseline score of 3 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's function with a specific verb and resource: 'List devices' and 'Returns a list of your devices.' It distinguishes from sibling tools like showDevice (single device) and deleteDevice, establishing its role as the comprehensive listing operation.
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 by stating 'List devices,' which clearly signals when to use it (to fetch a list), but it does not explicitly mention alternatives or exclusionary conditions. No guidance is provided on when to prefer listDevices over showDevice or other list tools, relying instead on the tool name and context.
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=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only operation. The description adds the HTTP GET method and the '/v2/custom-fields/{id}' path, but does not disclose error behavior, auth requirements, or response structure beyond what annotations already provide. This is adequate for a simple retrieval, but no additional behavioral context is given.
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 brief and front-loaded with the purpose. However, the first sentence 'Show custom field' is redundant with the title, and the description could be condensed to just the second sentence plus the endpoint. Still, it is not verbose.
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 GET-by-ID tool with robust annotations and one required parameter, the description is sufficient for an agent to understand the operation. It lacks an explicit description of the return payload, but given the tool's simplicity and the lack of an output schema, the provided context is adequate.
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 'id' parameter is fully described in the schema ('The ID of the custom field.'), and the description does not add further detail about format, source, or validation. With 100% schema coverage, the baseline 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 description clearly states the action ('Retrieves the details') and the resource ('existing custom field'), which distinguishes it from sibling tools like listCustomFields (which lists multiple) and update/delete operations. The HTTP endpoint further clarifies the specific resource being accessed.
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 details of a specific existing custom field identified by an id, you call this tool. However, it does not explicitly mention alternatives like listCustomFields or when not to use it, leaving the distinction to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety with readOnlyHint, idempotentHint, and destructiveHint. The description adds the HTTP GET endpoint and the 'existing device' qualifier, but does not disclose error behavior or the potentially large response when all include_* flags are set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence 'Show device.' is redundant with the title, but the subsequent sentences efficiently provide the endpoint and purpose without clutter.
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 get-by-ID tool with rich annotations and complete parameter descriptions, the description is mostly adequate. However, it does not mention the effect of include_* parameters on response size or describe the return value, though no output schema exists.
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 all eight parameters are fully documented in the schema. The description adds no extra parameter 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 and resource: 'Retrieves the details of an existing device.' The endpoint 'GET /v2/devices/{id}' further specifies the operation, and the singular 'an existing device' distinguishes it from listDevices.
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 guidance is given about when to use this tool versus alternatives like listDevices or showGroup. The description implies use for a specific device lookup by ID, but does not mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds the HTTP endpoint but does not disclose additional behavioral traits such as error handling, return format, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but includes a redundant opening 'Show update.' that repeats the tool name, wasting a few words. The rest is efficient.
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 single-parameter retrieval tool with rich annotations, the description is largely sufficient, though it lacks explicit return-value details and error behavior. Given the simplicity, this is adequate.
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 fully documents the 'id' parameter with a description. The tool description adds no further semantic detail about the parameter, so it relies on schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieves the details of an existing update,' using a specific verb and resource. This distinguishes it from sibling tools like listUpdates, which lists updates.
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 specific update by ID but provides no explicit guidance on when to use this tool versus listUpdates or alternatives. No exclusions or prerequisites are stated.
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 destructiveHint false, so the safety profile is clear. The description adds that it returns a list and specifies the API endpoint, but does not disclose pagination behavior or other operational details beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences long, and front-loaded with the core purpose. Including the API endpoint is useful and not verbose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with well-documented parameters and strong annotations, the description is sufficient. It states the scope and return type, and the API endpoint is a nice reference. Lack of output schema is offset by the clear 'Returns a list' statement and the fact that the schema covers inputs thoroughly.
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 parameters are fully documented in the schema. The description does not add any extra meaning about parameter semantics, but the baseline of 3 is appropriate given the schema's thoroughness.
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 custom field values' and specifies the scope: 'for the organization, groups, or devices.' It distinguishes from sibling tools like listCustomFields (which lists field definitions) by focusing on values, and the API endpoint adds precision.
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?
Usage context is implied by mentioning the scope (org/groups/devices) and returning values, but there is no explicit guidance on when to choose this over alternative tools like listCustomFields or updateCustomFieldValue. No exclusions or alternative names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong safety signals (readOnlyHint, idempotentHint, destructiveHint=false). The description adds the HTTP GET method, which is consistent with these hints but does not disclose additional behavioral details such as error handling, return format, or edge cases. With annotations present, the description adds modest value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using three short sentences to convey the action, resource, and endpoint. It is front-loaded with the purpose and contains no redundant or filler information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-tag retrieval with one well-documented parameter and rich annotations, the description is adequate. It does not explicitly state the return value (the tag object), but this is easily inferred from the tool name and GET endpoint, and there is no output schema that would require explanation.
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 of the parameter 'id' with the description 'The ID of the tag to retrieve.' The tool description does not add any further meaning beyond the schema, so it stays at the baseline 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 uses the specific verb 'retrieves' with the resource 'tag' and explicitly states the API endpoint (GET /v2/tags/{id}). This clearly distinguishes it from siblings like listTags, createTag, and deleteTag, making the tool's 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 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 specific tag by ID, but it does not explicitly mention alternatives or when not to use it. For example, it doesn't note that listTags should be used for listing all tags, so the guidance is limited to what can be inferred from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint: true and idempotentHint: true, covering the safety profile. The description adds little beyond restating 'Deletes an existing group' and providing the API endpoint. There is no contradiction with annotations, but no substantial additional behavioral context is disclosed.
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 short and front-loaded, but contains redundancy: 'Delete group' and 'Deletes an existing group' convey the same meaning. The API endpoint is useful. Overall it is concise and easy to scan, but the redundancy prevents a perfect score.
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 delete operation with one parameter and strong annotations, the description is mostly complete. It lacks details about return values or error handling, but no output schema exists and the annotations cover the destructive nature. The endpoint adds useful context, making it adequate for low 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?
The input schema fully describes the only parameter (id) with a clear description. The tool description does not add any further parameter semantics, but schema coverage is 100%, so the baseline 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?
The description clearly identifies the tool's function: deleting a group. It specifies the resource ('group') and action ('delete'), and includes the exact API endpoint. This distinguishes it from sibling tools like deleteDevice and deleteTag.
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 the use case: when you need to delete an existing group. It provides clear context without explicitly excluding alternatives like removeGroupDevices, but for a straightforward delete operation this is sufficient. No explicit when-not-to-use guidance is given, so it doesn't reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as readOnly, idempotent, openWorld, and non-destructive. The description adds the GET endpoint but no further behavioral context such as auth requirements, error handling, or return format. With strong annotations, this level of added detail is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences. The opening 'Show alert' is somewhat redundant with the title, but the rest is efficient and front-loaded with the core action. It earns near-perfect marks for scale.
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 single-ID retrieval tool with no output schema and comprehensive annotations, the description and schema provide sufficient context. It states what it does and the endpoint, and the parameter is fully documented. Minor gap: no explicit return value description, but 'retrieves details' implies the response.
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: the only parameter (id) is clearly described as 'The ID of the alert to retrieve.' The description adds no new parameter-level meaning beyond the schema, so the baseline 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?
The description states 'Retrieves the details of an existing alert,' which is a specific verb+resource combination. It clearly distinguishes showAlert from sibling listAlerts by focusing on retrieving a single alert by ID, and the API endpoint reinforces this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need details of a specific existing alert. It does not explicitly mention alternatives like listAlerts, but the context is unambiguous enough for an agent to infer appropriate usage.
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=false, but the description adds valuable context by noting that webhooks requiring authorization must include a write-enabled API key, and provides the HTTP endpoint. This goes beyond the structured metadata and clarifies the auth/reversibility nature of the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. There is slight redundancy between 'Trigger webhook' and 'Triggers an automation via a webhook,' but overall each sentence adds useful content (purpose, auth note, endpoint), making it efficient.
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 trigger operation with no output schema, the description covers purpose, auth requirements, and endpoint. It does not explain return values or failure behaviors, but given the simplicity and schema richness, it is largely complete. It could mention how to obtain the token via listAutomationWebhooks, but that is not strictly necessary.
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 fully documents token, device_ids, and additionalProperties. The description does not add parameter-specific meaning beyond the schema, but it does mention the endpoint which indirectly relates to the token parameter. Hence, 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 'Triggers an automation via a webhook,' specifying the action and resource. This distinguishes it from sibling read tools like listAutomationWebhooks and showAutomationRun, and the endpoint further clarifies its function.
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 when to use the tool (to trigger automations) and provides a prerequisite about authorization headers for webhooks requiring them. However, it does not explicitly contrast with alternatives like listAutomationWebhooks or showAutomationRun, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds the entity scope and the API endpoint but does not disclose additional behavioral traits like permission requirements or side effects. It is consistent with annotations and provides modest extra 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 brief and front-loaded, with the core action stated first. The additional sentence about the API endpoint is slightly cryptic but not verbose. It could be omitted, but overall it is succinct and 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 good schema descriptions and annotations, the description provides adequate high-level context. It identifies the target entities and the action. It doesn't explain return values (no output schema) or the force mechanism in depth, but those are covered in the schema. It is reasonably complete for its 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 descriptions cover the parameters well (75% coverage), including the force behavior and assigned_to_id semantics. The description only echoes the scope ('organization, group, or device') without adding significant new meaning beyond the schema. Baseline 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?
The description clearly states the tool's action: 'Update custom field value' and 'Set a custom field value for the organization, group, or device.' It identifies the resource (custom field value) and the scope (org/group/device), distinguishing it from sibling tools like updateCustomField (which updates the field definition).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it sets values for organizations, groups, or devices. While it doesn't explicitly contrast with alternatives, the scope definition makes the intended use clear. It lacks explicit 'when not to use' guidance but is not misleading.
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 fully cover the read-only, idempotent, non-destructive nature, so the description's burden is low. It adds the API endpoint, which is useful but does not disclose response shape or error behavior. This is acceptable for a simple GET, but no extra behavioral context is provided beyond the endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the tool name and a clear verb. The endpoint line adds reference value without padding. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-by-ID operation with full annotations and schema coverage, the description is adequate. It confirms the action and endpoint, but does not explicitly state the return payload (the group details) or potential error conditions, which would be expected in the absence of an output schema.
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 fully describes the only parameter 'id' with a clear description (100% coverage). The description adds only the nuance that the group exists ('existing group'), but otherwise adds no new semantic meaning beyond the 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 'Retrieves the details of an existing group,' giving a specific verb and resource. The mention of the REST endpoint further disambiguates it from sibling tools like showTag or showDevice.
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 use when you need details for a specific group ID, providing clear context. However, it does not explicitly mention alternatives (e.g., listGroups) or when not to use it, so it slightly misses the explicit guidance bar.
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?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds meaningful context: it filters to non-archived automations and specifies the exact return content (trigger URLs and accepted parameters). This goes beyond annotation already provided, though it doesn't discuss pagination or response format in detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and includes the endpoint as a practical reference. No wasted words or redundant repetition of the schema or annotations.
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?
With no output schema, the description compensates by stating what is returned (trigger URLs and accepted parameters) and the scope (non-archived automations). The endpoint provides additional context. Given the moderate complexity of a list operation with pagination, the description is sufficiently complete, though it could mention that all webhooks are returned regardless of automations.
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 covers 100% of parameters with detailed descriptions, so the description does not need to explain them. The description adds no parameter-level information, but the baseline of 3 is appropriate given high schema coverage. The endpoint also implies pagination behavior, which is already documented in parameters.
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 automation webhooks, distinguishing it from sibling tools like listAutomations and triggerWebhook. It also specifies what is returned (trigger URLs and accepted parameters) and includes the endpoint, providing a specific verb+resource pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: to list webhook trigger URLs and accepted parameters for non-archived automations. It does not explicitly name alternatives or exclusions, but the sibling context (listAutomations, triggerWebhook) makes the scope evident. The endpoint further anchors the usage.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior: it filters out archived automations and specifies the API endpoint, which is context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It front-loads the core purpose and includes one useful detail (non-archived) and one reference to the API endpoint. Every word earns its place.
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 simple list tool with well-documented parameters and strong annotations, the description is complete. It states the output type ('a list of non-archived automations'), and the absence of an output schema does not create ambiguity. The pagination parameters are already thoroughly described in the schema.
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 each parameter (limit, ending_before, starting_after) has a detailed description in the input schema. The tool description adds no additional parameter semantics, so the baseline 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?
The description clearly states the tool's purpose: 'List automations. Returns a list of non-archived automations.' This provides a specific verb ('List'), a resource ('automations'), and a scope ('non-archived'), which distinguishes it from related tools like listAutomationWebhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is for listing non-archived automations, and it provides the REST endpoint. It does not explicitly state when to use it versus alternatives, but the purpose is clear enough that an agent would know when to invoke it.
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?
The description adds valuable behavioral info beyond annotations: it states the no-op behavior for already-resolved alerts and that it returns the alert as-is. It also includes the endpoint. Annotations already cover readOnly/destructive flags, so this extra context is a plus.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences and an endpoint reference. The key information is front-loaded ('Resolve alert.') and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no nested objects), the description is complete. It explains the action, the idempotent behavior, the return value, and the endpoint, which is enough for an agent to select and invoke it 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?
The schema has 100% coverage for the single parameter 'id', with the description 'The ID of the alert to resolve.' The tool description does not add any additional parameter meaning beyond this, 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 the verb and resource: 'Resolve alert' and 'Resolves an active alert'. It is distinct from sibling tools like showAlert or listAlerts, using the specific action 'resolve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use it to resolve active alerts, and notes that already-resolved alerts are no-ops. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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