Tenable OT Security MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but the large number of query/list variants (e.g., query_attack_pathways vs get_communication_paths, query_vulnerabilities vs query_vulnerability_clusters) creates some potential for misselection. Descriptions are detailed enough to resolve most ambiguity.
Naming Consistency5/5
Tool names follow a consistent snake_case verb_noun pattern (list_, get_, query_, export_, find_), with only a few harmless outliers like summarize_environment and tenable_ot_status. The naming convention is highly predictable across the entire set.
Tool Count2/5
At 59 tools, the set is far beyond the recommended 3-15 range and feels heavy, with many archived variants and overlapping query tools. While the OT security domain is broad, the count is excessive and could overwhelm an agent.
Completeness2/5
The read-only surface is broad, but the server references write tools like update_policy and create_tag_group that are not actually provided, leaving lifecycle gaps. There is also no tool to execute scans, only to view scan configurations. The missing write operations and scan execution are significant gaps.
Average 4/5 across 59 of 59 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the context that these groups are 'soft-deleted,' which is a useful distinction from active groups. However, it does not disclose the list behavior (e.g., read-only nature), pagination via limit/after_cursor, or any other operational traits. The description is too sparse to inform an agent about side effects, authorization, or return details.
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 extremely brief ('Soft-deleted EM-level user groups'), which is concise but under-specified. It is not a complete sentence and lacks a verb, making it more of a label than a functional description. While there is no waste, the brevity results in missing critical information, so it fails the test of every sentence earning its place.
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?
This is a simple list tool with no annotations and an output schema (content not shown). However, the description is insufficient given the rich set of sibling tools. It does not explain how this tool differs from list_archived_user_groups, list_em_user_groups, or list_user_groups, beyond the label 'EM-level.' It also does not mention pagination behavior or the meaning of 'archived' beyond soft-deleted. For an agent to select and invoke it correctly, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description contains no information about the 'limit' and 'after_cursor' parameters. The names hint at pagination, but the description does not compensate for the lack of schema documentation. The agent is left to guess how these parameters affect the results, with no guidance on defaults, format, or relationship.
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 'Soft-deleted EM-level user groups' is a noun phrase, not a verb phrase. It clarifies that 'archived' means 'soft-deleted' and specifies the Enterprise Manager scope, which helps distinguish from sibling tools like list_archived_user_groups. However, it does not explicitly state the action of listing, relying on the title and tool name for that. It is not a tautology but lacks a clear imperative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Given the existence of similar siblings such as list_archived_user_groups, list_em_user_groups, and list_user_groups, the description does not explain why an agent should choose this specific tool or what differentiates it beyond the title. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions that only the first 25 included rules are returned, which is a useful behavioral trait, but it does not cover error handling, permissions, or the full response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but is a fragment rather than a complete sentence. It under-specifies the tool's behavior, and while there are no wasted words, it sacrifices necessary clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no annotations, and an output schema not shown, the description should provide more context. It only mentions the 25-rule limit, omitting the tool's overall purpose, parameter guidance, or any usage context, leaving it incomplete for an agent to confidently invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, group_id, with no description and 0% schema description coverage. The description does not mention group_id or explain what a rule group ID is or how it is used, failing to compensate for the schema gap.
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 'One rule group with the first 25 included rules' is a noun phrase without an explicit verb, though it clearly implies returning a single rule group. It adds a distinguishing detail about the 25-rule limit but relies heavily on the tool name and title for context.
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 get_rule_group versus alternatives like list_rule_groups or get_tag_group. The description lacks any context about selection criteria, prerequisites, or exclusionary conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the response content ('one EM-level user group with its roles and member preview') but does not mention permissions, error behavior, whether archived groups are included, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of fluff, but it is a fragment rather than a complete sentence. It conveys key information but lacks a verb and structured phrasing, making it slightly awkward.
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 get-by-id tool with many siblings, the description is too sparse. It does not clarify when to use EM-level vs non-EM, whether the group is active or archived, or what happens for missing IDs. The output schema exists but the description does not adequately complement 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 schema has 0% description coverage and the description does not explain the group_id parameter format or provenance. The title's 'by id' and the parameter name provide some obvious meaning, but the description adds no value beyond that.
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 identifies the specific resource as 'EM-level user group' and notes it includes 'roles and member preview', which distinguishes it from sibling tools like get_user_group. However, it uses a noun phrase rather than an explicit verb, relying on the title for the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_user_group or list_em_user_groups. The description does not mention any exclusions or prerequisites, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add one meaningful behavioral detail: the response includes up to 100 items, implying a limit. However, it does not disclose error behavior, authorization needs, or return format details beyond what the output schema might provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short with no filler, making it concise. However, it is under-specified and lacks structure; it does not fully communicate the tool's purpose or behavior. The brevity is not a virtue because it omits essential usage and parameter context.
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 tool's simplicity (1 parameter, output schema) and the availability of sibling tools, the description is incomplete. It does not explain when to use this get tool over list_protocol_groups, nor does it mention error conditions or pagination details. The 'up to 100 items' limit is helpful, but the overall context is too sparse for an agent to select and invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, group_id, with 0% coverage from the description. The description does not explain the parameter's format, purpose beyond its name, or any constraints. The title says 'by id', which indirectly clarifies group_id, but the description itself adds no value for parameter understanding.
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 'One protocol group with up to 100 of its items' identifies the resource (protocol group) and a key scope limitation, but lacks an explicit verb like 'retrieve' or 'get'. It reads as a fragment rather than a clear action statement, though it does distinguish this from list_protocol_groups by indicating it returns a single group with items.
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 list_protocol_groups or get_rule_group. The description does not mention any prerequisites, exclusions, or recommended contexts. The title hints at retrieval by ID, but the description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'paginated', which is already inferable from the limit and after_cursor parameters in the schema. It does not disclose behavior such as whether archived groups are excluded from normal listing, permission requirements, or how pagination works.
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 extremely short and front-loaded, containing only four words. While it is not bloated, it borders on under-specification, omitting context that would be valuable for an agent.
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 list tool with an output schema and two optional params, the description captures the essential distinction (archived/soft-deleted) but lacks guidance on pagination semantics, usage scenarios, and behavioral expectations. It is incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only says 'paginated' without explaining how limit and after_cursor function. The agent is left inferring that these are pagination controls, with no details about cursor format or default behavior.
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 'Soft-deleted port groups, paginated' clearly identifies the resource (port groups) and the distinguishing feature (soft-deleted/archived). While it lacks an explicit verb, the tool name 'list_archived_port_groups' provides the action. It differentiates from siblings like list_port_groups and other list_archived_* 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 for when to use this tool versus alternatives such as list_port_groups or other archived list tools. The description only states what it lists but does not mention when to choose it over the non-archived version.
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 are absent, so the description carries the full burden. It discloses only that results are paginated and groups are soft-deleted. It doesn't explain pagination mechanics, auth requirements, rate limits, or what 'soft-deleted' implies. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it's a noun phrase fragment lacking a verb. It's under-specified rather than efficiently structured. For a simple tool it's acceptable, but it doesn't follow a clear 'verb + resource' pattern.
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 list operation with an output schema, the description covers the basics (resource type and pagination). However, it doesn't mention ordering, one-page behavior, or relationships to sibling tools. Given the low complexity, it's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'paginated', which alludes to limit and after_cursor. It doesn't explain their meanings, defaults, or how to use after_cursor for subsequent pages. The agent must infer from names and types, which is insufficient.
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 tool name explicitly states 'list archived schedule groups', and the description 'Soft-deleted schedule groups, paginated' clarifies that it returns soft-deleted (archived) schedule groups with pagination. While there is no explicit verb, the meaning is clear and distinguishes from list_schedule_groups (active groups).
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. It doesn't mention that list_schedule_groups is for active groups, nor any criteria for choosing this tool. The description is a fragment with no usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that the tool returns exactly one port group and caps its port-range items at 100, which is a meaningful detail beyond the schema. However, it omits information about error handling, pagination, or whether archived groups are included, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the core return shape and a key limit. It is not verbose and the information is front-loaded. It could be improved by adding a verb, but for the information it carries, it is appropriately concise.
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 simplicity of the tool (one parameter, output schema present), the description is mostly adequate but has gaps. It explains the one-group result and the 100-item cap, but does not clarify behavior when there are more than 100 items or how to retrieve additional ones. Without annotations, more detail on error scenarios or access requirements would make it 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 input schema has only one parameter, group_id, with 0% description coverage. The description does not elaborate on what group_id represents or how it is used. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema descriptions or provide additional context such as format or constraints beyond the schema's basic string type.
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 'One port group with up to 100 of its port-range items' is a noun phrase that does not clearly state the action of retrieving, though it does specify the result scope. It adds a useful detail about the item limit but lacks a clear verb+resource statement beyond the tool's title. It does not strongly distinguish itself from sibling get_* tools aside from mentioning port-range items.
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 list_port_groups or list_archived_port_groups. It does not state prerequisites or exclusions. The usage is implied by the tool name and parameters but not explicitly described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only discloses that the tool returns soft-deleted protocol groups and is paginated. It does not mention permissions, return structure, or any side effects, leaving significant behavioral aspects undisclosed.
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 concise with no wasted words. It is front-loaded with the key information (soft-deleted, paginated), though it is somewhat under-specified, it remains appropriately sized for a simple list tool.
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 list tool with an output schema and two conventional parameters, the description covers the basic purpose and pagination. However, given the many sibling list tools, it would benefit from explicit differentiation and parameter context, so it is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description does not explain 'limit' or 'after_cursor'. While the parameter names are conventional, the description adds no meaning beyond what the schema already implies, failing to compensate for the low 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 identifies the resource (protocol groups) and the scope (soft-deleted), which distinguishes it from the sibling tool 'list_protocol_groups'. The phrase 'Soft-deleted protocol groups, paginated' is a fragment but conveys the purpose effectively, though it lacks an explicit verb.
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 term 'soft-deleted' implies it is for archived items, but there is no explicit mention of using other list tools for active groups or any 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?
With no annotations, the description must carry behavioral disclosure. It adds the insight that these are 'soft-deleted' and that results are 'paginated,' which is useful. However, it does not clarify permissions, recoverability, or other behavioral nuances, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, bordering on under-specification. While concise, it omits needed context, so it does not fully earn its place as a standalone explanation.
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?
This is a simple list tool with an output schema, so return values are covered. However, the absence of annotations and parameter descriptions makes the tool less complete for an agent deciding whether and how to invoke it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only hints at pagination via 'paginated' but does not explain `limit` or `after_cursor`, their defaults, or how they interact.
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 'Soft-deleted rule groups, paginated' clearly identifies the resource (rule groups) and scope (soft-deleted/archived), distinguishing it from sibling `list_rule_groups`. However, it lacks an explicit verb like 'list' in the description, relying on the title for clarity.
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 `list_rule_groups` or other archived list tools. No context or exclusions 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?
No annotations are provided, so the description carries the transparency burden. It discloses a meaningful behavioral constraint ('up to 100 member items'), which helps set expectations. However, it does not mention error handling, access permissions, or behavior for non-existent IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the essential scope and a key limit. Every word earns its place; no fluff or 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?
For a simple get-by-id tool with one parameter and an output schema, the description is adequate but not complete. It highlights the 100-item limit but omits potential edge cases like archived groups or what happens when a group has more than 100 members, leaving the agent to infer behavior.
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 the group_id parameter beyond what the schema already provides (a string titled 'Group Id'). With 0% schema description coverage, the description should compensate, but it adds no parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get a tag group by id' provides the verb and resource, and the description adds that it returns one tag group with up to 100 member items. This distinguishes it from list_tag_groups, which returns multiple groups, though the description itself lacks an explicit verb.
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 gives no guidance on when to use this tool versus alternatives like list_tag_groups or get_port_group. There is no mention of prerequisites, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It states the response contains one group with roles and member preview, which is useful. However, it does not mention permissions, error behavior, whether archived groups are retrievable, or any read-only guarantee. For a simple read operation, this is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single fragment with no filler or repetition. It front-loads the key outcome and earns its place by noting the ICP-level scope and the roles/member preview, which adds value over the title and schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and an output schema, the tool is low complexity, and the description covers the essential return shape. However, it lacks usage guidance and does not clarify the meaning of 'ICP-level' or how this tool relates to archived vs. active user groups, leaving some ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not mention group_id or its expected format. The parameter name is self-explanatory, and only the 'ICP-level' qualifier hints at context beyond the schema. The description fails to compensate for the missing parameter documentation.
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 indicates the tool retrieves a single ICP-level user group with its roles and member preview. The title 'Get a user group by id' adds retrieval semantics, and 'ICP-level' distinguishes it from sibling tools like list_user_groups and get_em_user_group. However, 'ICP-level' is not explained, so the purpose is clear but not fully self-contained.
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 list_user_groups, list_archived_user_groups, or get_em_user_group. The description implies a singular lookup by id but does not state exclusions, prerequisites, or context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It states that the tool lists 'soft-deleted' groups, which hints at a read-only operation on a filtered dataset, but it does not explain return details, pagination behavior, or any side effects. The description adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise, front-loaded phrase with no wasted words. It is appropriately short for a simple list operation, though it could have included a verb or usage note without losing 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 tool has a simple interface with two optional pagination parameters and an output schema. The description conveys the core resource and scope, but lacks any context about the meaning of 'ICP-level' or the distinction from active groups. It is minimally viable but not fully complete for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention the 'limit' and 'after_cursor' parameters. Although these are standard pagination parameters with self-explanatory names, the description offers no added meaning, leaving the agent to infer from the schema alone.
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 'Soft-deleted user groups at the ICP level' clearly identifies the resource (user groups) and scope (soft-deleted/archived, ICP level). It distinguishes itself from sibling tools like list_user_groups (active) and list_archived_rule_groups (different resource). The verb 'list' is implied by the title, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 explicitly state that this is for archived/soft-deleted groups only, nor does it mention using list_user_groups for active groups. Usage context is only implied by 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?
The description discloses that the tool paginates ('Page through'), returns only active groups, and that each entry contains assigned roles and a sample of member users. This adds behavior beyond the function name. However, it does not explicitly state read-only nature, pagination mechanics, or any rate limits, which are unaddressed. Since annotations are absent, the description carries the full burden but still has gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and scope. It avoids redundancy and every sentence adds information: the pagination behavior and the content of each entry.
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 tool with an output schema, the description is quite complete. It specifies the scope (active, ICP-level), the pagination style, and what fields are returned (roles, sample members). The output schema covers return structure, so no need for added detail. However, it does not clarify how this tool relates to other user-group list tools (e.g., list_em_user_groups), which could cause selection ambiguity.
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 input schema has two parameters (limit, after_cursor) with 0% description coverage. The description only implies pagination but does not explain the meaning or usage of 'limit' or 'after_cursor.' It fails to compensate for the lack of schema descriptions, leaving parameter semantics unclear.
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: 'Page through every active user group at the ICP level.' It specifies the resource (user groups), scope (active, ICP-level), and action (page through). It also differentiates from siblings like list_archived_user_groups (active vs archived) and get_user_group (paginated list vs single group) by emphasizing 'every active' and 'ICP-level.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool vs alternatives. It does not mention that list_archived_user_groups should be used for archived groups or that get_user_group retrieves a specific group. The only implicit hint is the word 'active,' but no direct comparison or alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It indicates a read operation ('Fetch') and adds what is included (recipient list, SMTP details), but it does not disclose error behavior, authorization requirements, or whether archived groups are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb, and zero filler. Efficient and appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are documented elsewhere. The description gives enough context for a simple get-by-id, though it could mention error handling or its distinction from find_email_groups_using_smtp_server.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the group_id parameter beyond what the name and title imply. It adds no format, constraints, or example values to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the exact resource ('one email group'), adding the scope 'recipient list and bound SMTP server details.' This clearly distinguishes it from sibling list tools like list_email_groups and search tools like find_email_groups_using_smtp_server.
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 have a specific group_id and need full details, but it does not explicitly recommend alternatives like list_email_groups for listing all groups, nor does it state any exclusions or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination ('Page through') and the presence of specific fields (em_level, roles, member preview), which is useful context. However, it does not mention authentication requirements, rate limits, or any edge-case behaviors like whether the list is sorted or if there are permission prerequisites. For a read-only list operation, this is adequate but not comprehensive.
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 wasted words. The first sentence states the core purpose, and the second adds valuable output details. It is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return value details are covered elsewhere. The description provides sufficient context for the tool's scope (active EM-level groups) and key output (em_level and member preview). It lacks explicit alternatives or edge-case handling, but for a straightforward listing tool with an output schema, it is arguably complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the two parameters (limit, after_cursor). The description only hints at pagination via 'Page through' but does not explain the semantics of limit or after_cursor, nor does it mention that the parameters are optional with defaults. This undercompensates for the lack of schema descriptions, leaving the agent to rely on conventional parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Page through') and resource ('every active EM-level user group'), clearly distinguishing this tool from siblings like list_user_groups and list_archived_user_groups by the 'EM-level' and 'active' qualifiers. It also states key output fields, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving active EM-level user groups, but does not explicitly mention alternatives or exclusions. While 'active' implies archived groups are excluded, there is no direct guidance on when to use this vs. list_em_archived_user_groups or list_user_groups, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: the server does NOT cluster server-side, meaning the AI must perform clustering itself. It also explains the two traversal modes. However, it doesn't describe behavior when no arguments are supplied (both optional) or mention that it's a read-only operation, which is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured: a lead sentence stating the core purpose, followed by bullet-style mode explanations. It front-loads the most important information and adds necessary caveats without excessive verbosity.
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 5 parameters, no annotations, and an output schema. The description covers the primary use cases and the no-clustering caveat, but it misses parameter semantics for 3 params and doesn't cover the empty-args edge case. Given the tool's complexity, it is above minimal but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains `asset_ids` and `cve_substring`, including their behavior in different modes, but omits `global_limit`, `per_asset_limit`, and `severity_at_least`. Since 3 of 5 parameters lack semantic meaning in both schema and description, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a per-asset → vulnerabilities join, with two distinct query modes (asset_ids and cve_substring). This distinguishes it from sibling tools like query_vulnerabilities and get_asset_vulnerabilities by framing it as a relational join for identifying common CVEs, exploit chains, and single-patch leverage points.
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 explicit context for when to use the tool: to spot common CVEs across assets, exploit chains, or single-patch leverage points. It explains the two modes and notes they can be combined. However, it doesn't explicitly say when not to use it or name alternative tools, so it's not a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds meaningful context about pagination ('Page through') and the meaning of 'tag_type'. It does not explicitly state read-only nature or permissions, but for a list operation this is reasonable. It goes beyond a generic list description.
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 main purpose. The second sentence about tag groups is useful context, though the third sentence about 'tag_type' is tangential to the list operation itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description provides adequate context about what tag groups are and the tool's scope. However, it omits details about pagination parameters and does not mention when not to use it, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain 'limit' or 'after_cursor'. Instead, it discusses 'tag_type', which is not an input parameter, offering no help for the actual parameters and potentially confusing users.
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 'Page through every tag group' with a specific verb and resource. It also defines what tag groups are, distinguishing this from 'get_tag_group' which retrieves a single group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for enumerating all tag groups, but it does not explicitly state when to use it over alternatives like 'list_eligible_tags' or 'get_tag_group', nor does it mention any 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?
With no annotations, the description discloses the tool's non-narrative behavior and the joined-data nature, which is valuable. However, it does not mention potential performance implications, permission requirements, or side effects. The 'single shot' phrasing hints at efficiency but doesn't elaborate. The disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. It front-loads the core function and includes a useful caveat about narrative generation. Every sentence contributes to understanding the tool's purpose and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output composition, and the context in which the AI uses the result. The output schema exists, so return details are provided by the schema. It does not explain parameter defaults or caps, but for a bundle-returning tool with clear components, the context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter meaning beyond naming. Parameters like max_peers, max_vulns, max_events, and recent_event_window_iso are not described, nor how they interact with the returned bundle. The description mentions 'recent events' but not how the window is controlled, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'one asset's full relational bundle' and enumerates the exact components (asset core, vulnerabilities, events, peers). The title additionally reinforces the distinction from narrative generation. This differentiates it from sibling tools like get_asset or get_asset_vulnerabilities which return individual data views.
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 a complete relational picture is needed in a single call, and explicitly notes the AI consumes this bundle for narrative writing. It does not name specific alternatives, but the sibling list indicates separate getters exist. While not an explicit 'when-not-to-use', the contextual framing provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It discloses pagination behavior and the data included (recipients, SMTP server, last-modified), which is useful. Yet it omits potential requirements (e.g., permissions) or any side-effect-free guarantee, though for a list operation this is somewhat implicit.
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 three sentences, front-loaded with the primary action, and each sentence adds value: the action, the returned fields, and the business context. 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?
The tool is simple with a paginated list and an output schema, so the description need not explain return values. It provides enough context about the data and purpose, though it could mention whether special permissions are required or how the results are ordered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain 'limit' or 'after_cursor' at all. While the parameter names are somewhat self-explanatory, the cursor format and default behavior are undocumented, leaving a gap that the description should have filled given zero 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?
Description states the specific action ('Page through every email group') and resource ('email groups in the deployment'), clearly distinguishing it from sibling tools like get_email_group (single group) and find_email_groups_using_smtp_server (filtered lookup).
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 for when to use this tool—when you need to enumerate all email groups—and mentions their role in detection policies. However, it does not explicitly contrast with alternatives or state 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?
With no annotations, the description must carry the behavioral burden. It discloses that only active port groups are returned and that pagination is used ('Page through'). However, it does not explain what defines 'active', the ordering, or the behavior of the cursor. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and defines a domain concept. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema and familiar pagination parameters, the description provides sufficient context: it defines what port groups are, notes their relationship to PortPolicy, and states the active filter. However, it could be more complete by explicitly naming the alternative for archived groups and elaborating on cursor usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only says 'Page through', which hints at pagination but does not explain 'limit' or 'after_cursor' semantics. The parameter names and defaults are self-evident, but the description adds minimal value for understanding their usage or format.
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 pages through every active port group, using a specific verb ('page through') and resource ('port groups'). It distinguishes from sibling tools like 'list_archived_port_groups' and 'get_port_group' by explicitly noting 'active' and the list nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for active port groups but does not explicitly state when to use this tool versus alternatives like 'list_archived_port_groups'. The term 'active' provides clear context, but there are no explicit exclusion or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately conveys that the tool pages through results and describes the content of each item. However, it does not explicitly state that the operation is read-only or outline any error behavior, rate limits, or authorization requirements, which is a moderate gap for a tool with no 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 extremely concise, comprising two sentences. The first sentence front-loads the primary action and scope, while the second clarifies the returned item composition. There is no wasted wording, and every sentence contributes useful 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 two-parameter list tool, the description covers the core purpose and result content, and the existence of an output schema supplements return details. It also clarifies the 'active' scope, which is important given archived variants. The main omission is explicit pagination traversal guidance, but 'Page through' implies cursor-based usage, making this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It only says 'Page through', which hints at pagination but does not explain the roles of 'limit' and 'after_cursor'. The schema provides default values and titles, but the description adds minimal extra meaning for how to use these parameters effectively.
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 a specific verb+resource combination: 'Page through every active protocol group.' It clearly indicates a paginated listing operation and distinguishes from siblings by explicitly noting 'active', which contrasts with the archived variant (list_archived_protocol_groups) and the single-item getter (get_protocol_group).
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 by specifying it applies to 'every active protocol group', implicitly excluding archived groups and single-group retrieval. However, it does not explicitly name alternative tools for those cases, so the guidance is clear but not fully explicit about when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It adds behavioral context: pagination ('Page through'), scope ('active'), and response preview ('up to 25 included rules'). It does not mention authentication, read-only nature explicitly, or rate limits, but listing is inherently non-destructive and the preview detail is useful.
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 long, front-loaded with the main action, and every sentence adds distinct information (what, definition, response content). 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 list tool with an output schema, the description is quite complete: it covers scope (active), pagination behavior, and what each entry contains. The output schema handles return structure, so the description does not need to explain that. Missing details like sorting order or whether archived groups are excluded are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining 'limit' and 'after_cursor'. It only says 'Page through', which vaguely implies pagination but does not explain these parameters or their roles. The schema provides names and defaults, but the description adds minimal semantic value for the 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 action ('Page through every active rule group'), specifies the resource (rule groups), and differentiates from sibling list_archived_rule_groups by explicitly limiting scope to 'active'. It also defines what a rule group is, removing ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for active rule groups) and contrasts with the archived sibling through the word 'active'. However, it does not explicitly name alternatives or state 'use X for archived groups', so it falls slightly short of full explicitness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'returns full detail' but does not mention read-only nature, error handling, authentication requirements, or potential side effects (though likely none). This is a significant gap for a tool with zero annotation support.
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 long, front-loaded with the primary purpose, and contains no filler. Every sentence earns its place: the first states what it does, the second explains when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the existence of an output schema, the description is largely complete. It covers the main usage context effectively. Minor gaps exist around error behavior and explicit safety, but these are partially mitigated by the clear read-style purpose and the 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'by id' and references event ids from query_events, which adds some context. However, it does not explain the format, constraints, or possible values for event_id beyond what the schema's type 'string' already implies. For a single required param, this is adequate but not exceptional.
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: 'Returns full detail for a single OT event by id.' It uses a specific verb ('returns full detail') and resource ('single OT event'), distinguishing it from sibling tools like query_events which likely list multiple events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use after `query_events` returns an id of interest, or when a finding or case references a specific event.' This directly tells the agent when to invoke this tool versus alternatives, such as querying for lists of events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the soft-delete semantics, that definitions and historical membership are preserved by Tenable, and that archived groups stop appearing in active views. It does not mention read-only safety or return format, but the core behavior is transparent.
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 two sentences with useful structure via dash and semicolon. It is efficient and each clause adds context. The phrase 'by Tenable' is slightly extraneous but does not undermine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional params, output schema present), the description adequately explains the archived concept and pagination. It lacks explicit guidance on when to use active vs archived lists, but overall it is complete enough for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'Page through' suggests pagination, but it does not explain the `limit` or `after_cursor` semantics, cursor format, or how defaults behave. The added value for parameters is minimal.
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 operation ('page through'), the resource ('archived asset groups'), and differentiates from active lists by explaining soft-deletion via `archive_asset_group`. It also clarifies that these groups are excluded from active views, distinguishing it from sibling tools like `list_asset_groups`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to view soft-deleted asset groups that no longer appear in active views. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses filtering by asset and tag type and the tag_type enum values, but does not describe pagination behavior (after_cursor) or what determines eligibility beyond what's stated. The read-only nature is implied by "without guessing tag ids" but not explicitly confirmed.
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?
Three sentences, all informative: purpose, filters, and usage context. The enum list is compact but valuable. 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?
The description provides sufficient context for most use cases, especially with the output schema available. Key gaps are the unexplained limit and after_cursor parameters, but the core behavior and workflow are well explained.
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?
Description explicitly covers asset_id and tag_type, including the enum values for tag_type. However, limit and after_cursor are not mentioned, and schema descriptions are absent (0% coverage). This partially compensates for the lack of schema detail but not completely.
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?
States it "List controller tags that could be added to a tag group," specifying both the action and resource. The title "Discover tags eligible for a tag group" reinforces this. Distinguishes from sibling list tools by focusing on tag eligibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says "Use this before `create_tag_group` to discover what's available without guessing tag ids," providing a clear when-to-use context. It does not mention when-not or alternative tools, which keeps it just below a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns raw events ordered chronologically, includes joined fields, and does not analyze sequences. This is valuable behavioral context, though it omits details like pagination or response size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and adds a clarifying example and explicit non-capabilities. Every sentence earns its place; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered, but the input parameters are not well documented. The description gives the tool's purpose and example usage but omits practical parameter details (formats, allowed values), leaving a notable gap 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds minimal parameter meaning. It mentions 'time window' (mapping loosely to since/until) but does not explain limit, event_types, date formats, or filtering semantics beyond that. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns events in a time window with specific fields (classification, firing policy, IPs) in chronological order. The title and description explicitly differentiate this from motif analysis, making the purpose unambiguous even among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the intended use case ('The AI uses this raw sequence to detect patterns') and provides a concrete pattern example. It also states what the server does NOT do (no motif detection, scoring, labeling), which helps set expectations, though it does not explicitly name alternative tools like query_events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses an important behavioral consequence (groups will lose their delivery path) and implies a read-only lookup through 'return'. However, it does not mention pagination behavior or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the action and use case are front-loaded. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward lookup with an output schema, and the description covers purpose, main parameter, and a critical use scenario. Minor gaps around pagination parameters exist, but the overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only explains smtp_server_id ('Given an SMTP-server id'), leaving limit and after_cursor entirely undocumented. With 0% schema description coverage, the description fails to clarify the full parameter set.
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 a specific verb ('return') and precise resource ('email groups bound to an SMTP server'), with the title clarifying routing. It distinguishes itself from generic list/get tools by tying results to an SMTP server id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies a use case ('Useful before retiring an SMTP server') and explains the consequence of removal, giving an agent a clear when-to-use signal. It does not name alternative tools, but the context makes it clear this is the SMTP-specific lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It accurately states the tool returns a full specification, implying a read operation, but does not disclose any error behavior, authorization needs, or side effects. For a simple get-by-id this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both information-dense. No filler or redundant restating of the title.
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?
The tool is simple, has an output schema, and the description covers purpose and usage context. The guidance to use list_active_scans first is essential for correct invocation. Given the simplicity, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It indirectly references the parameter via 'by id' and ties it to list_active_scans, but does not explicitly define scan_id's format or required status. The schema indicates required, but the description adds limited extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Returns the full specification for one active-scan job by id,' using a specific verb and resource. It clearly distinguishes from siblings like list_active_scans and get_active_scan_executions by referencing 'one active-scan job' and the usage context.
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 second sentence explicitly provides a workflow: use after list_active_scans returns a job of interest, or when reading parameters before modifications. This gives clear context, though it lacks an explicit when-not clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool only audits executions and does not trigger them ('execution is triggered by humans, not this server'), and lists statuses and source types. This adds valuable context beyond a simple read operation, though it does not cover permission or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and return fields. The second sentence adds a useful usage caveat without fluff. Every clause contributes meaning, and it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context, and a key behavioral trait, and an output schema exists to explain return values. It lacks only minor details like limit default behavior or error handling, which are not critical for a simple read tool. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implies scan_id via 'one active scan' and completely omits the 'limit' parameter. This leaves a significant gap in understanding the parameters beyond the schema's bare names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns past execution records for one active scan' and enumerates exact fields, distinguishing it from sibling tools like get_active_scan (scan details) and list_active_scans (list scans). The verb 'Returns' and resource 'past execution records' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use this to audit when a scan was last run and whether it succeeded,' giving a clear context. It also adds a caveat that execution is human-triggered, not by this server. However, it does not name alternatives or provide explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It usefully discloses that the record shape varies by subtype and gives concrete examples, which is valuable behavioral context. It does not mention auth, errors, or missing-id behavior, but for a straightforward read operation this is adequate.
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 with no filler. The first sentence states the action and target, while the second adds necessary subtype details, making it both efficient 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?
For a low-complexity one-parameter getter with an output schema available, the description covers the core functionality and subtype variability well. It could mention error handling or how to obtain group_id, but these are not critical given the tool's simplicity.
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 input schema has no description for group_id (0% schema coverage), and the description only says 'by its id', which just restates the parameter name. No format, source, or example is provided, so the description does not meaningfully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch'), resource ('one asset group's full record'), and scope ('by its id'), making the purpose immediately clear. It also distinguishes itself from sibling list/get tools by explaining subtype-specific response shapes.
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 clearly implies when to use this tool: when you need a single asset group's full record by id. It does not explicitly mention alternatives or exclusions, but the context (sibling tools like list_asset_groups) makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return fields, mentions the `predefined: true` flag for system scans, and explicitly states that no scan-execution tool exists, which prevents agents from attempting a write action. It does not discuss auth or rate limits, but these are less critical for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core return-value specification, followed by usage guidance and a crucial caveat about scan execution. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the output shape by listing fields, provides a clear use case, and adds a behavioral nuance about predefined scans. The only gap is the undocumented `limit` parameter, but given the tool's simplicity and the presence of an output schema, the overall context is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (`limit`) with 0% description coverage, and the description does not mention or explain it. The agent is left to infer its purpose from the name and default value alone. Given the low coverage, the description should have compensated by stating that `limit` controls how many scans are returned, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns Tenable OT active-scan job specifications' and enumerates the specific fields returned (name, operation type, category, trigger, etc.). The verb+resource structure distinguishes it from sibling tools like get_active_scan, which fetches a single scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool: 'Use this to audit what scans are configured.' It also provides a when-not by noting that 'this server does not expose any tool that runs a scan,' preventing misuse. However, it does not name alternative tools for related operations, such as getting a single scan's details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that results are paginated ('Page through'), that each entry includes membership shape and a 'display_tag' field, and that only active groups are returned. It does not mention rate limits or auth, but for a read-only list operation, this is substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every clause adds value. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with a simple schema and an output schema present, the description covers the key aspects: what is returned (membership shape, display_tag), the active filter, and the intended use. The one gap is explicit handling of pagination parameters, but the output schema likely includes cursor info, and the phrase 'Page through' is sufficient for an agent to infer basic usage.
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 input schema has 0% description coverage, so the description must compensate for the limit and after_cursor parameters. It does not — it only says 'Page through' without explaining that limit controls page size and after_cursor provides pagination cursor. The parameter names are somewhat self-explanatory, but the description adds no semantic detail beyond the schema, which itself has no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Page[s] through every active (non-archived) asset group in the deployment.' This is a specific verb+resource+scope combination that distinguishes it from siblings like list_archived_asset_groups and get_asset_group. The scope is explicit.
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 an explicit use case: 'Use this before creating to avoid duplicating an existing group.' It implies that this tool is for active groups, contrasting with archived ones, but does not explicitly name alternatives or exclusions. This is clear context, though not full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool is READ-ONLY, highlights high latency on large deployments, and notes the search parameter is a single-term substring. It also explains that structured export filters are not exposed due to undocumented filter shapes. This is meaningful behavioral context, though it doesn't cover authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear purpose statement, a bulleted alternatives section, and a final notes section. It is somewhat lengthy but every sentence adds value. The structure makes it scannable. Minor redundancy in mentioning 'READ-ONLY' twice (once in text, once as bullet) but overall 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?
Given the output schema exists, return values don't need explanation. The description covers purpose, usage alternatives, search limitations, latency, and read-only behavior, which is thorough for a bulk export tool. It omits pagination details and start_at usage, but those might be in the output schema. Overall, it is complete enough for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains `search` (single-term substring) and why structured filters are absent. It does not explain `limit` or `start_at` semantics, leaving half the parameters undocumented. The description adds some value for search but is insufficient for the other 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 states a specific verb and resource: 'Bulk export of FINDING INSTANCES' with a precise definition ('one record per (vulnerability or policy violation x affected asset)'). It also distinguishes from siblings by comparing with get_asset_vulnerabilities and query_policy_findings, clarifying scope as all findings across the deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'Choosing between the finding tools' section that names alternatives, describes when to use each (start with get_asset_vulnerabilities for a specific asset, query_policy_findings for filtered policy findings), and positions this tool for bulk offline analysis/reporting. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds valuable context about the response shape varying by kind: TimeInterval returns start/end times, while RecurringGroup returns weekly windows under 'schedules'. This goes beyond simple getter behavior, though it omits error handling or side-effect notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second adds necessary detail about shape variance. No wasted words, front-loaded with the primary action.
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 one parameter and an output schema, the description is sufficiently complete. It supplements the schema by explaining how the response varies by group kind. It could mention what happens if the ID does not exist, but that is not essential for a getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the single parameter group_id is self-explanatory from the name and title. The description does not elaborate on the parameter format or constraints, but the meaning is unambiguous. This is adequate compensation for a trivial parameter.
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 begins with 'Fetch one schedule group,' which clearly states the action (fetch) and resource (schedule group). It indicates this is a single-item getter, distinguishing it from the sibling 'list_schedule_groups' tool. The title reinforces the 'by id' scope.
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 clearly implies use for retrieving a single schedule group by ID, and the sibling list includes list_schedule_groups for bulk retrieval. However, there is no explicit statement of when to use this tool over alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and adds key behavioral traits: 'READ-ONLY' and 'High latency'. It also states that it returns full plugin records in bulk. However, it does not mention pagination details or export API specifics like continuation tokens, which would be useful for a high-latency bulk export.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear primary statement, a usage preference note, and a behavioral note. Every sentence adds valuable information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the absence of annotations, the description provides solid context: what it does, when to use it, read-only safety, and latency expectations. It would be more complete if it mentioned how to handle the high latency (e.g., polling or long waits) and whether pagination exists, but for a bulk export tool this is reasonably sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not explain `limit`, `search`, or `start_at`. The parameter names are somewhat self-explanatory, but the description's statement about needing the 'whole catalog' actually obscures the optional filtering parameters, leaving the agent without clear guidance on how to use them.
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 performs a bulk export of plugin definitions via Tenable OT's export API, with a specific verb ('export') and resource ('plugin definitions'). It also distinguishes itself from the sibling `query_plugin_definitions` by positioning this as the whole-catalog bulk option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to prefer `query_plugin_definitions` for interactive lookups and to use this tool when the whole catalog is needed. It also notes high latency, which further guides choice for non-interactive bulk operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses key traits: returns only peer IDs (not full asset data), requires follow-up calls to get_asset for enrichment, and supports recursive traversal. While it doesn't mention rate limits or pagination, the disclosed constraints are significant and actionable for an AI agent.
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 three sentences, each earning its place: the first states the core function, the second explains the ID-only output and its enrichment path, and the third contextualizes recursive use. No filler or redundancy; front-loaded with the action.
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 an output schema exists, return details are covered. The description provides strong context: graph adjacency usage, peer ID enrichment, and recursive expansion. It falls short only in explaining all input parameters, but for an overall tool with moderate complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies asset_id via 'involving one OT asset' and the tool name, but never explicitly names the parameter. The limit and since parameters are entirely unexplained; the description does not mention limiting results or filtering by time. This leaves meaning gaps for 2 of 3 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's purpose: 'Returns observed L2 communication links involving one OT asset, with peer asset id, protocols seen, traffic / conversation count, and first/last-conversation times.' This specific verb+resource combination distinguishes it from siblings like get_asset, which returns asset details, and query_assets, which handles broader search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use this tool: 'The consuming AI uses this as the graph adjacency for attack-path reasoning; call again on a peer's id to expand further.' It also names an alternative for enrichment: 'call `get_asset` on each peer id to enrich with name / vendor / type.' This clearly frames usage in relation to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool pages over all active schedule groups, surfaces each entry's kind and windows, and connects to policy mutations. This gives a clear read-only listing behavior, though it does not explicitly state side-effect-freeness or pagination mechanics.
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?
Three sentences, no waste. Each sentence adds value: purpose, entry contents, and relational context. Front-loaded with the core action.
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?
Despite having an output schema, the description provides sufficient context for a simple list tool: scope (active), entry details (kind, windows), and the broader use case (policy schedule resolution). No critical information is missing for an agent to decide 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?
Schema description coverage is 0%, so the description must compensate. It does so only via the phrase 'Page through', implying pagination via limit and after_cursor. Parameter names are self-explanatory, but no explicit link or usage detail is provided for the cursor. This is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Page through') with a clear resource ('every active schedule group'), and differentiates from siblings like list_archived_schedule_groups and get_schedule_group by explicitly scoping to active groups and plural listing.
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 clearly implies when to use this tool: for listing active schedule groups, especially as a reference for policy mutation schedule arguments. It does not explicitly name alternatives or exclusions, but the 'active' qualifier and sibling list_archived_schedule_groups provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explicitly declares READ-ONLY, explains that plugins appear regardless of environment impact, and details that `search` performs single-term substring matching. It also discloses that structured filters are not exposed due to unconfirmed behavior, adding useful limitation context. However, it does not mention pagination or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: three short paragraphs covering purpose, alternatives, and parameter behavior. It is front-loaded with the core purpose, and every sentence adds value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is highly informative for a query tool, covering catalog semantics, usage alternatives, and search limitations. However, it does not distinguish this tool from `export_plugin_definitions` (a sibling tool) nor explain the pagination parameters (`limit`, `start_at`), leaving minor gaps in an otherwise thorough description.
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 input schema has zero parameter descriptions, so the description must compensate. It only explains `search` (single-term substring match) and leaves `limit`, `sort_by`, `start_at`, and `descending` completely undocumented. Users are left to guess their meaning, formats, and usage, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns Tenable plugin definitions (the vulnerability checks themselves) and lists the returned fields (id, name, family, severity, VPR score, assets affected). It explicitly distinguishes this from per-asset findings, making the tool's role unambiguous and differentiating it from siblings like get_asset_vulnerabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use `get_asset_vulnerabilities` for asset-specific vulnerabilities and `export_findings` for a bulk dump of findings. It also clarifies what this tool is not for (per-asset findings) and explains the omission of structured filters, giving clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden. It discloses the shape of results (fields like firstHitTime, activeHits, status, joined assets) and explains filter semantics. It does not discuss pagination or side effects, but for a read-only query tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, a bulleted filter list, and relevant examples. It is slightly longer than strictly necessary, but each sentence contributes useful information and the organization aids comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and an output schema exists. The description explains the core behavior, common filters, and result fields. It does not cover edge cases or alternative output formats, but the provided context is sufficient for most uses, especially given the output schema is available separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by detailing severity_at_least, status, mitre_technique, and since with concrete examples and format expectations. It leaves limit, search, plugin_id, and policy_id implicit, but those are relatively self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Returns per-asset findings for one or more detection policies.' It clearly defines the output as rows of (policy × asset × hit count) and distinguishes this from sibling query tools like query_vulnerabilities or query_events by focusing on policy findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use cases: 'see which assets keep tripping a policy (often a tuning gap), or which assets are MITRE-mapped to a specific technique.' This gives strong contextual guidance, though it does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It clearly states 'READ-ONLY' and 'High latency on large deployments', and explains the `search` parameter is a single-term substring, plus why structured filters are omitted. This is solid transparency, though it does not detail pagination or response size limits, leaving a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each earning its place: purpose, usage guidance, search clarification, filter rationale, and a final read-only/latency warning. The description is front-loaded with purpose and reads cleanly without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate parameter count and an output schema, so the description needn't detail return values. It covers when to use, what it returns, latency, read-only nature, and a key parameter clarification. It falls just short of perfect by not mentioning pagination or how `start_at` interacts with large exports, but for an agent selecting a tool it is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for `search` by describing it as a substring, and clarifies why structured filters are absent. However, `limit`, `sort_by`, `start_at`, and `descending` are left to be inferred from their names, which is acceptable but not fully compensatory at this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Bulk asset export') and clearly states the return value ('full asset records') and use cases (offline analysis, inventory reconciliation, feeding another system). It also distinguishes itself from the sibling `query_assets` by positioning itself for bulk/offline needs, leaving no ambiguity about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use this tool vs `query_assets` ('PREFER query_assets for interactive questions... Use this tool when you genuinely need whole records in bulk'). It also states what is not exposed (structured filters) and why, providing clear guidance on limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It lists the specific vulnerability fields returned (CVEs, CVSS v3 score/vector, exploit flags, age, disclosure date, vendor solution), giving a detailed picture of behavior. It does not mention pagination/limit behavior or error cases, but for a read-only tool this is acceptable.
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 tightly written sentences. The first sentence front-loads purpose and output contents, the second provides alternative usage. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, output fields, and usage context. Since an output schema exists, listing return fields is a bonus rather than a requirement. Missing details about limit/pagination and error handling are minor gaps given the overall clarity.
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 0%, so the description must compensate. It does clarify that the input is 'one OT asset', which maps to asset_id, but it does not explain the limit parameter. The schema's default and type suffice for limit, but a brief mention of 'limit number of returned vulnerabilities' would strengthen the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns the open vulnerabilities (Tenable plugins) affecting one OT asset' – a specific verb (Returns) and resource (vulnerabilities) with clear scope (one asset). It also distinguishes itself from the sibling query_vulnerabilities by emphasizing asset-scoped access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool versus the alternative: 'Use query_vulnerabilities for global vuln filtering (KEV-only, exploit-available, severity floor, etc.); this tool is asset-scoped.' This gives clear contextual guidance and exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It explicitly states 'READ-ONLY' and discloses that the result includes 'the assets it affects.' It also warns about the numeric id format, which is a behavioral/constraint detail beyond the schema. It does not mention error behavior or rate limits, but for a simple getter, this is adequate.
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 focused sentences plus a standalone 'READ-ONLY' label. It front-loads the main action, then the critical id caveat, with no filler or repetition. Every sentence adds value.
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 single-parameter getter with an output schema, the description is complete. It defines what is returned (plugin definition plus affected assets), the id type requirement, and the read-only safety profile. No significant gaps for an AI agent to select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only 'integer' with no description (0% coverage), so the description must compensate. It does so by clarifying that the plugin_id is numeric, not the UUID, and gives a concrete example ('e.g. 500123'). This adds essential 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 the tool's purpose: 'Returns one plugin definition by its NUMERIC plugin id, including the assets it affects.' It uses a specific verb ('Returns') and resource ('one plugin definition'), and distinguishes itself from sibling tools by emphasizing the numeric id type and the inclusion of affected assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage caveat about the id type ('Note the id is an integer (e.g. 500123), not the UUID') and labels the tool as READ-ONLY, but it does not explicitly state when to use this tool versus alternatives like query_plugin_definitions or export_plugin_definitions. No explicit exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It states 'READ-ONLY', describes the behavior for each kind, and notes that monitored_networks includes disabled subnets as blind spots. This goes beyond a bare function, though it doesn't discuss pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then uses a compact bullet list for the kind variants. Every sentence serves a purpose, and the structure makes the options easy to scan without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values don't need to be spelled out. The description covers purpose, use cases, alternatives, read-only nature, and parameter semantics for the required parameter. It omits pagination behavior, but that's minor given the presence of an output schema and the otherwise thorough description.
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 0% description coverage, so the description must compensate. It thoroughly explains the 'kind' parameter with enumerated values and their meaning, but does not explain 'after', 'limit', or 'target_id'. The description adds significant value for the primary parameter but leaves three parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Returns the appliance's network CONFIGURATION — what it is set up to watch.' It explicitly contrasts itself with sibling tools list_segments_and_zones and get_communication_paths, which report observed data, clearly differentiating its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete when-to-use scenario: 'Reach for this when inventory looks wrong' and explains why using this tool helps diagnose missing assets in query_assets. It also names alternatives as reporting observed data, providing clear context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that subtotals are 'best-effort' and that only filters supported by Tenable are populated, and it defines bucket categories. It doesn't explicitly state the operation is read-only, but 'Returns a snapshot' and the absence of side effects imply it.
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 efficient and front-loaded with the main purpose. It adds a brief note on best-effort behavior and bucket definitions without unnecessary verbosity. Minor redundancy with the sibling list could be trimmed, but it's well-structured.
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?
The description is complete for a zero-parameter summary tool. It covers the general content, the best-effort caveat, and the key classification buckets. Since an output schema exists, return format details are already structured, so the description does not need to repeat them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters; it instead describes the output categories and subtleties, which 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 a specific verb ('Returns') and resource ('snapshot of the operator's OT environment'), clearly listing the content (asset, events, vulnerabilities, sensors, topology, policies). It distinguishes itself from siblings by positioning as a broad overview versus specific query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Ideal as the first call when the AI doesn't yet know the deployment's shape and scale,' giving a clear usage context. It does not name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states what the tool returns (every segment with all its fields and every zone with its definition). It also explains what a zone is, adding conceptual clarity. While it doesn't discuss pagination, performance, or side effects, this is a simple read-only list operation, and the description gives a complete picture of the output. The lack of explicit side-effect disclosure is acceptable given the read-only nature implied by 'Returns', but some detail on response scope or limitations could push it higher.
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 and well-structured. It is front-loaded with the primary action ('Returns Tenable OT's segmentation') followed by specific details about segments and zones, and then a clear use-case sentence. Every sentence earns its place: the first defines the output, the second describes the attributes, and the third provides actionable guidance. There is no redundancy or fluff.
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 (no parameters) and the presence of an output schema, the description is complete. It covers what the tool returns (segments and zones with specific fields), what a zone represents, and when to use it (compliance questions). The compliance context adds valuable domain-specific guidance that an agent needs to select the right tool. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, and the input schema is empty. The schema description coverage is trivially 100%. The description does not need to explain parameters since there are none. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools, and the description does not miss any opportunity to add value here.
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: to return Tenable OT's segmentation, specifically listing every segment with its attributes (VLAN, subnet, asset-type filter, system flag, archived flag) and every zone. The verb 'Returns' combined with the specific resource (segmentation) makes the action unambiguous. It also distinguishes itself from sibling tools like list_asset_groups and list_network_config by focusing on segments and zones as defined by the IEC 62443 model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies when to use this tool: 'Use this to answer compliance questions about the IEC 62443 Zone & Conduit model, NERC CIP Electronic Security Perimeters, or NEI 08-09 defense-in-depth.' This gives a clear context. However, it does not mention when not to use it or explicitly contrast with alternative list tools such as list_asset_groups or list_network_config, so it falls short of the highest 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?
With no annotations provided, the description takes on full responsibility for behavioral disclosure. It usefully discloses that 'The status filter applies client-side after fetch', which is a non-obvious behavioral nuance. It also enumerates the returned attributes, but does not discuss pagination, permissions, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: three sentences pack the purpose, usage context, and a behavioral caveat without redundant words. The structure front-loads the core purpose, then adds a clear use-case, and finishes with a relevant implementation detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with an output schema, the description covers what data is returned, when to use it in the broader tool ecosystem, and a critical behavioral detail (client-side filtering). The only minor omission is parameter enum values, but the simplicity of the tool and presence of an output schema make the description sufficient 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?
Schema description coverage is 0%, so the description must compensate for parameter clarity. It adds meaning only for 'status' by explaining it is applied client-side, but does not clarify valid values or the 'connection_status' parameter's semantics. The parameter names are self-explanatory to a limited extent, but the lack of enum values or descriptions leaves room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Returns every Tenable OT sensor in the deployment with its current status...' which clearly specifies a verb, resource, and target attributes. It also differentiates from sibling tools by positioning the tool as a visibility check before using query_assets/query_events, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to verify visibility coverage before drawing conclusions from query_assets / query_events' and explains the key rationale ('an offline sensor means absence of evidence, not evidence of absence'). This is direct when-to-use guidance with named alternatives and a logical grounding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden and does well by disclosing pagination mechanics (`has_more`, `end_cursor`), the `total_count` semantics, the 500-item limit, and the field set returned. However, it does not explain the behavior of the `hidden` and `search` parameters, nor does it state how multiple filters combine (e.g., AND vs OR), so some behavioral aspects remain implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is well-structured: an introductory sentence, a pagination paragraph, and a bulleted list of filter values. The extensive `kind` enum is necessary because the schema lacks enum definitions. The content is information-dense and front-loaded, though slightly verbose in the tag/disambiguation paragraph.
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 10-parameter list endpoint with no annotations or schema descriptions, this description is unusually complete. It covers pagination, filter vocabulary, count semantics, and a practical edge case. The presence of an output schema means return-value details need not be repeated. Minor omissions around `hidden`, `search`, and cross-filter AND/OR behavior keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides detailed enums for `kind`, `category`, and `criticality_at_least`, explains match behavior for `vendor` and `name_contains`, and elaborates on `tags` semantics including exact strings and ANY matching. It also clarifies `limit` and `after` in the pagination context. Two parameters (`hidden`, `search`) remain unexplained, which prevents a higher score.
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 core function: 'Returns a list of OT assets in the Tenable OT deployment, filtered by the provided criteria.' It also enumerates the asset fields returned and distinguishes itself from related tools like `get_asset` and `get_asset_vulnerabilities`, making the list-level 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: it explains how to use `total_count` to answer 'how many' questions, how to paginate with `after`/`has_more`, and when to call `get_asset` or `get_asset_vulnerabilities` on returned IDs. It also includes a practical use case for using tags to disambiguate duplicate-named assets, which is concrete 'when to use' guidance beyond generic alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It discloses key behaviors: returns the asset itself plus peer IDs, includes protocols and counts, does not compute paths, and returns IDs only requiring enrichment via get_asset. It doesn't mention pagination or max_peers behavior, but the core behavioral traits are well covered.
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?
Three sentences, each earning its place: returns, usage, exclusions and enrichment path. Front-loaded with the core result, then practical guidance, then limitation. No redundancy or filler.
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?
Despite having an output schema (so return-value details are covered elsewhere), the description explains the relational nature, iteration strategy, and enrichment workflow. It gives the AI enough context to use the tool correctly and reason about attack paths, making it complete for its purpose.
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 0%, so the description must compensate. It implicitly clarifies entry_asset_id by describing the asset's neighborhood, but max_peers is never mentioned. The description adds meaning for the primary parameter but leaves the secondary parameter entirely undocumented, a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the asset's 1-hop network neighborhood with protocols and conversation counts. It explicitly distinguishes itself from path-computation tools by saying the server does NOT compute paths, which differentiates it from siblings like get_communication_paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: use this as the graph the AI walks, call again on each peer ID to expand, and call get_asset to enrich peer IDs. It also clarifies what not to expect (no path computation) and assigns that responsibility to the AI, making alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the read-only nature via 'Returns' and describes both the plugin and affected assets. It doesn't discuss error handling or authentication, but the output schema exists, and the provided context about exposure breadth adds behavioral insight.
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 three sentences, front-loaded with the core function, followed by use case and alternative. Every sentence contributes value without redundancy or excess length.
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 one-parameter tool with an output schema, the description covers purpose, usage, parameter provenance, and relationship to sibling tools. It omits failure modes, but that is a minor gap given the output schema and low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It does so by identifying plugin_id as the Tenable plugin ID (not CVE) and explaining how to obtain it via query_vulnerabilities. This gives the parameter practical significance beyond a bare string field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a single Tenable plugin (vulnerability) by ID along with affected OT assets, using a specific verb ('Returns') and resource. It distinguishes itself from siblings by explicitly contrasting with CVE-based lookup and referencing query_vulnerabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains when to use this tool ('reason about exposure breadth') and provides an alternative path for CVE lookup ('call query_vulnerabilities first then fetch by plugin_id'). This is clear, actionable guidance that differentiates from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses pagination behavior (`total_count`, `has_more`, `end_cursor`, `after`), the structure of returned events, and the potential for very large result sets. This goes beyond the schema and is crucial for correct invocation and response handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs and bullet points, front-loading the purpose and then providing pagination details and filter vocabulary. Every sentence contributes valuable information without redundancy or fluff, making it easy to scan.
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 complexity of an 11-parameter query tool with an output schema, the description covers the essential aspects: purpose, usage, pagination, and filter semantics. It doesn't need to describe return values because the output schema exists. The guidance about narrowing large result sets is critical and complete enough for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaningful explanation for a few key parameters (severity_at_least, event_type, since/until) and the `after` cursor in the pagination context, but does not elaborate on other parameters like `dst_ip`, `src_ip`, `search`, `resolved`, `policy_id`, or `limit`. Thus it partially compensates but leaves many parameters undisclosed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns OT detection events matching the filter criteria, newest first,' which is a specific verb+resource. It distinguishes itself from sibling tools like `get_event` (for full detail on a single event) and other query tools by focusing on detection events and including filter examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: 'Use this to investigate alert windows, policy-firing patterns, source/dest IP context, or events in a specific time window.' It also guides toward `get_event` for full detail, and advises narrowing filters before paging, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries behavioral transparency. It discloses pagination behavior (total_count, has_more, end_cursor), the nature of results (CVEs, CVSS, exploit flags, age, solution), and the server-side filtering limitation. It makes clear the tool is a query operation without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, a pagination explanation paragraph, and bullet-style filter explanations. Every sentence earns its place and adds value; it is appropriately sized for the tool's complexity.
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 complexity, an output schema, and no annotations, the description is remarkably complete. It explains result contents, pagination, total_count for 'how many' questions, and filter vocabularies. It also tells the agent when to use a complementary tool. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explicitly explains severity_at_least, cve, family, and source with natural vocabulary. It also explains 'after' through pagination (pass end_cursor as after). However, the 'search' parameter is not mentioned at all, and 'limit' is only implicitly referenced via page size, so not every parameter is illuminated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns Tenable plugins (vulnerabilities) matching the filter criteria' with a specific verb and resource. It distinguishes itself from sibling query tools like query_assets and query_events by focusing on vulnerabilities and listing the exact return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use this tool versus get_vulnerability: 'Call get_vulnerability on a returned plugin id to see every affected asset.' It also explains pagination usage with after/has_more/end_cursor, and notes filtering limitations (KEV flags are not filterable). Lack of explicit when-not-to-use alternatives prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It discloses return fields, special null semantics for 'backplane', the distinction between backplane IDs and asset IDs, and the special format of imported tags. It also clarifies relationships with other tools, providing substantial behavior beyond a simple 'returns asset'.
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?
Description is front-loaded with the main purpose, then efficiently adds critical details in subsequent sentences. Each sentence earns its place: the backplane nuance, tag format, and invocations context are all valuable. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not enumerate return values, yet it still explains non-obvious aspects like backplane nullness and project-import tags. It also positions the tool within a workflow (after query_assets, before get_asset_vulnerabilities), making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), and the description adds usage context by saying the id comes from query_assets. However, it does not clarify the exact format or type beyond 'id', leaving some ambiguity. That said, for a single simple parameter, the provided guidance is sufficient to invoke the tool correctly.
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 begins with a specific verb and resource: 'Returns the per-asset bundle for one OT asset by id', followed by a detailed list of included fields. This clearly distinguishes it from sibling tools like query_assets (which lists assets) and get_asset_vulnerabilities (which fetches vulnerabilities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: 'Call after query_assets returns an id of interest.' It also directs when NOT to use it for vulnerabilities: 'For the asset's open vulnerabilities call get_asset_vulnerabilities separately.' This is explicit, actionable guidance with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses asynchronous behavior, null-field behavior for never-processed uploads, and an empirically confirmed caveat that it tracks CSV-type imports only. It warns against interpreting null as failure for project-file uploads and directs to query_assets, adding critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then provides practical polling guidance, then a clearly-marked empirical caveat. Every sentence carries necessary information, and the structure is easy to scan despite the caveat's length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params) and output schema exists, so the description doesn't need to explain return values. It covers the essential operational context: async behavior, null semantics, and a critical exception, making it fully complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default and there are no parameter semantics to clarify. The baseline for zero-param tools is 4; no additional parameter information is needed or possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Check') and resource ('processing status of the most recent file uploaded via Tenable OT's Manual Uploads data source'), clearly distinguishing this tool from siblings like query_assets. It also names the related upload tool for full context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use it (after a manual upload, poll if not yet updated), what to do if it hasn't updated, and when NOT to rely on it (project-file/OTD uploads), citing an alternative (query_assets). This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the structure of the returned configuration (AND'd rows of OR'd include/exclude conditions), the fact that it includes every field exposed by the edit surface, and the important fact that policy mutations are full replaces—meaning you must see the full current state before updating. This goes beyond a simple 'fetch' and reveals significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the core purpose, the second differentiates from the summary tool, and the third gives a critical usage warning. Every sentence earns its place, and the information is front-loaded with the key action and differentiating details. It is neither too long nor short.
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?
The description is contextually complete for a get-by-id tool. It lists the key fields returned (scope, schedule, severity, notifications, protocol/port group), notes the special case for Communication/Protocol-schema policies, and includes the crucial behavior of update_policy being a full replace. The output schema exists, so return format details need not be in the description. This gives the agent all needed context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, policy_id, with no schema description (0% coverage). The description clarifies that the tool fetches by id, so the parameter refers to the policy identifier. While it doesn't explicitly explain where to find the id (e.g., from list_detection_policies), the parameter name and 'by id' are sufficient for a simple string parameter. The description adds enough meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Fetch one policy's COMPLETE configuration by id' with specific scope details (source/destination asset-group, schedule, severity, notification actions). It explicitly distinguishes itself from list_detection_policies which returns a summary, and from update_policy. This is a specific verb + resource with clear differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Unlike list_detection_policies's summary, this returns every field...' and 'Call this BEFORE update_policy — Tenable OT's policy mutations are full replaces, not patches'. This tells the agent when to use this tool, which alternative to use instead, and the critical prerequisite for update_policy. Excellent and directly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses the schema structure (4 fixed slots, value types), the mapping concept, and how other tools consume this schema. It also explains that read tools output labels directly while write tools translate, giving the agent a comprehensive behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: it leads with the primary purpose, then explains the schema's internal details, then provides usage guidance and sibling relationships. Every sentence adds useful information without redundancy or fluff.
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 (no params) and the presence of an output schema, the description covers all necessary context: what the tool returns, why the schema exists, and how it interacts with read/write tools for custom fields. It is complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so schema coverage is trivially 100%. Per the baseline rule for 0 parameters, a score of 4 is appropriate; there are no parameter semantics to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Returns the asset custom-field schema', using a specific verb and resource. It clearly explains that custom fields are 10 fixed slots mapped to labels and value types, distinguishing this from sibling list_ tools that operate on other resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Call this before reading or writing custom-field values' and differentiates when read tools already surface labels automatically versus when write tools need the schema to translate labels. This provides clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses important behavior: server-side supports pagination only, and category/enabled/search filters are applied client-side. It also advises increasing `limit` for large deployments, adding practical context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a one-sentence purpose, a usage/alternative line, and a technical note. Every sentence contributes 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?
The description covers purpose, usage, an alternative tool, and critical pagination caveat. Since an output schema exists, return details are not needed, making the description comprehensive for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema-coverage, the description adds meaning to `limit` ('increase `limit` to capture more before filtering') and clarifies that category/enabled/search are client-side filters. It doesn't individually explain `paused`, but the overall filter behavior is conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Returns OT detection policies — the rules that fire events' and enumerates key attributes (level, flags, event-type, counts). It also distinguishes itself from `query_policy_findings` by directing users there for per-asset hits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear scenarios: 'audit which policies are configured, which are noisy, or which are paused.' It also names the alternative tool for per-asset hits, fulfilling the when-to-use vs alternative requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is READ-ONLY, explains the impact block's verdict (live vs archived policies), and warns about full-replace mutations in Tenable OT. This is rich behavioral context beyond what any annotation would 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 relatively long but densely informative. Every sentence serves a purpose, and the bullet-point structure for `kind` values makes it easy to scan. It avoids fluff and tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, four parameters, and an existing output schema, the description is complete. It covers the tool's role, usage context, parameter semantics, and expected verdict structure. The agent has everything needed to decide when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It thoroughly explains `kind` and `target_id` (including when `target_id` is needed). It doesn't explicitly define `after`/`limit`, but they are clearly pagination parameters and contextually obvious. The description adds substantial meaning for the core 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's purpose: 'Answers what breaks if I change this?' and identifies it as the impact check before writes on shared objects. It explicitly enumerates the relationship types via `kind`, distinguishing it from sibling 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance ('the impact check to run BEFORE any write that touches a shared object'), explains when each `kind` is appropriate, and advises checking both directions for completeness. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It states READ-ONLY behavior, never returns the API key, and discloses what is reported (latency, error). Sufficient for this simple status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and then usage guidance. Every word earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter status tool with an output schema, the description covers purpose, usage timing, and safety (read-only, no key leak). Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline per rules is 4. The description adds no parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports server reachability and authentication to the configured Tenable OT deployment, with latency and error details. It uses a specific verb ('report') and resource, distinguishing it from sibling query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call this first when other tools are failing, providing a clear diagnostic use case. It also differentiates between appliance/credential problems and query problems, which is actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and that it touches no OT data. Also explains that the server does not guess enum values, which can cause silent failures, and the default behavior of dumping types the server still needs.
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?
Well-structured with a concise purpose sentence, a rationale section, and bullet-point parameter explanations. Every sentence earns its place, and key information is front-loaded.
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 3-parameter introspection tool, the description covers purpose, usage, parameters, safety, and the context of why the tool exists. The output schema covers return values, so no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains each parameter in plain language, including the default of type_names when omitted. This fully compensates for the 0% schema description coverage and adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reads the deployment's own GraphQL schema, listing enum values, input-object shapes, and root fields. This is a specific verb+resource and distinguishes the tool from sibling data-query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: resolving SchemaNotConfirmedError by dumping required types, and checking if the appliance exposes a top-level query. Tells the agent exactly when to call with no arguments and unblocks gated filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP-server-Tenable-OT-V2 MCP server](https://glama.ai/mcp/servers/aqamahn/MCP-server-Tenable-OT-V2/badges/card.svg)](https://glama.ai/mcp/servers/aqamahn/MCP-server-Tenable-OT-V2)

Score Badge

Copy to your README.md:

[![MCP-server-Tenable-OT-V2 MCP server](https://glama.ai/mcp/servers/aqamahn/MCP-server-Tenable-OT-V2/badges/score.svg)](https://glama.ai/mcp/servers/aqamahn/MCP-server-Tenable-OT-V2)

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/aqamahn/MCP-server-Tenable-OT-V2'

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