Tenable Identity Exposure MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have clearly distinct purposes, but there is slight overlap among tie_deviances, tie_deviances_by_checker, and tie_deviances_by_directory. However, descriptions clarify that they differ by date filtering and scoping, so ambiguity is minimal.
Naming Consistency5/5All tools use the consistent 'tie_' prefix and follow snake_case naming. Naming patterns are predictable: nouns for entity listings (tie_alerts, tie_attacks) and verb_noun for search actions (tie_search_ad_objects). No mixed conventions.
Tool Count5/515 tools is well-scoped for the Tenable Identity Exposure domain. Each tool covers a distinct aspect (alerts, attacks, deviances, profiles, search, topology) without unnecessary duplication or missing core functionality.
Completeness5/5The tool set comprehensively covers the API surface: CRUD via tie_resource_action, specific queries for alerts, attacks, deviances, scores, topology, and search. The tie_recent_activity tool fills a gap by merging IoE and IoA timelines. No obvious missing operations.
Average 4/5 across 15 of 15 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It does not mention that create/update/delete are destructive, required permissions, or error handling. The example for delete lacks warning, and the impact of invalid resource names is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with Args and Examples sections, and front-loads the purpose. Every sentence is informative, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and multiple resource/action combinations, the description covers parameter usage thoroughly but lacks details on return format, error handling, and pagination specifics. It is adequate but incomplete for a generic CRUD tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant value by explaining each parameter (resource, action, id, body, params) with examples. It clarifies usage beyond the schema's type definitions, though the format for params is not fully detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs CRUD operations on TIE resources, with examples listing specific resources. It distinguishes from sibling tools which are resource-specific, but does not explicitly highlight its generic nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like tie_alerts or tie_attacks. The description provides examples but does not indicate prerequisites, context, or alternatives for specific resource operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. For a search tool, stating it is read-only would be helpful but is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line purpose followed by a parameter list. It is well-structured and front-loaded, though it could be slightly more compact by omitting redundant wording in the parameter lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain the return format, pagination behavior, or result fields. Given that the tool has pagination parameters (page, per_page), this omission reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description provides parameter descriptions in the 'Args' block (e.g., 'Search string to match against AD object names/attributes'). This adds meaning beyond the schema, though it could be more specific about what attributes are searched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb-resource statement: 'Search Active Directory objects (users, computers, groups, OUs) by name or attribute.' It explicitly lists the object types, which distinguishes it from other tie_ tools that deal with events, alerts, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not explicitly say when to use it versus alternatives. However, the sibling tools are all different (alerts, attacks, etc.), so the purpose implies usage context. Lacks explicit 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only describes the basic function and parameters, omitting critical details like authentication, error handling, rate limits, and side effects. This is insufficient for a generic API call tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a structured Args/Returns format. Every sentence adds value without redundancy. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 13 sibling tools for specific endpoints, the description lacks guidance on when to use this generic tool. It explains the return value (parsed JSON) but omits potential errors or pagination behavior. It is minimally adequate but not fully 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to all four parameters (method, path, params, body) with clear explanations and examples, compensating for the 0% schema description coverage. However, it could provide more detail on path formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: making direct HTTP calls to any Tenable Identity Exposure API endpoint. It uses a specific verb and resource, and it is easily distinguishable from sibling tools which target specific endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for any endpoint but does not explicitly guide when to use this generic tool versus the dedicated sibling tools (e.g., tie_alerts, tie_attacks). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states the action without mentioning whether the operation is read-only, requires special permissions, or has any side effects, pagination behavior, or output format. The term 'search' implies read-only, but it is not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise one-sentence purpose, followed by a well-structured Args list. Every line adds necessary detail, and there is no redundant or filler content. The structure is easy to parse and appropriately sized for the 6-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. While the parameter documentation is complete, the description lacks any indication of the return value, response structure, or potential limitations like pagination. Given the absence of an output schema, this leaves a notable gap for an agent to understand what the tool actually returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section thoroughly documents all six parameters, including formats (e.g., ISO 8601 for dates), defaults (e.g., profile_id default 1), and examples (e.g., ordering object). This fully compensates for the 0% schema description coverage, providing meaning beyond the bare type and title information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Search'), resource ('AD security events'), and scope ('within a date range'). This distinguishes it from siblings like 'tie_search_ad_objects', which searches AD objects instead of events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching security events but provides no explicit guidance on alternatives or when not to use. A clear context is present, but no exclusions or alternative tools are mentioned, leaving the agent to infer from the tool name and sibling list.
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 present, so the description carries the full burden. It discloses the output scope (domains, forests, trust relationships) and the read-only nature is implied by 'Get', but it does not mention authentication, permissions, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one purpose sentence followed by a single parameter definition. Every word adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description does a good job of stating what the tool returns (domains, forests, trust relationships). It lacks details on response structure or edge cases, but it is sufficient for a simple read-only topology query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a type and default for profile_id. The description adds essential meaning by clarifying it is a 'Security profile id', compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('Active Directory topology') with an explicit enumeration of the content (domains, forests, and trust relationships). This clearly distinguishes it from sibling tools like tie_search_ad_objects or tie_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving AD topology but provides no explicit guidance on when to use this tool versus alternatives. There are no exclusions or prerequisites mentioned, so the context is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that this is a listing operation, implying read-only, and describes pagination parameters. However, it does not disclose any response format, result ordering, or potential side effects beyond what can be inferred from 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single-purpose sentence followed by a clean argument list. It is front-loaded with the action, and every line serves a purpose, covering all parameters without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the parameter documentation is clear, there is no output schema and the description does not mention what the returned alert objects contain. For a list tool, an agent needs to know the shape of the results to process them correctly, making the description incomplete in that respect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), but the description explicitly explains each parameter: profile_id, page, per_page, and archived. This fully compensates for the lack of schema descriptions and adds meaning beyond type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List alerts for a security profile' with a specific verb and resource. It distinguishes from sibling tools like tie_scores and tie_topology by focusing on alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to list alerts filtered by profile, pagination, and archived status. It does not explicitly mention when not to use it or alternatives, but the purpose is sufficiently clear to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the return format as a list of {directoryId, score} and interprets the score direction ('higher is better; scores reflect outstanding IoE deviances'), which is valuable context. The verb 'Get' and 'Returns' imply a read-only operation, though it does not explicitly state side-effect freedom 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a purpose statement, a return-value explanation, and a parameter description. Every sentence earns its place with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description covers the essential input and output semantics. It explains the returned list structure and score interpretation, making it nearly complete. It does not define 'IoE deviances' or cover pagination, but these may be domain-specific or irrelevant for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds the meaning 'Security profile id' and notes the default value, which the schema alone does not provide. This is adequate for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get per-directory security scores for a profile', specifying the verb, resource, and scope. It distinguishes this from sibling tools by focusing on scores rather than raw deviances or topology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for retrieving a summary of security posture per directory, but it does not explicitly mention when to choose this over alternatives like tie_deviances_by_directory, nor does it state exclusions. The context is clear but no direct comparisons 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?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It mentions that the data comes from the API key, which implies no separate login flow, and the verb 'Get' implies a safe read operation. However, it does not explicitly state that no state is modified or describe error handling for invalid keys, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-argument tool, the description is complete: it states the returned information (identity, roles, permissions) and the source (API key). No output schema exists, but the description sufficiently explains the return value's nature for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully documents argument expectations. The description adds no parameter details but this is unnecessary; a baseline of 4 is appropriate since there are no parameters to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('current user's identity, roles, and permissions'), distinguishing it from sibling tools which all focus on data listings, scoring, or actions rather than user 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/5Does 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 (to retrieve current user info) and notes the API key as the source, but does not explicitly mention alternatives or exclusions. Since no sibling tool serves this purpose, the guidance is adequate without being explicit.
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 of behavioral disclosure. It discloses server-side date filtering, defaults to the last 24h, truncation of attribute values when verbose=False, pagination behavior, and show_ignored semantics. It stops short of mentioning authentication, rate limits, or error handling, but for a read-only search tool it provides 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-sentence summary, a clarifying note about time windows, and a bulleted Args list. It is longer due to 11 parameters, but each sentence and bullet is informative. A tighter wording (e.g., combining some defaults) could slightly improve it, but it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description covers all parameters, defaults, and endpoint behavior. It mentions server-side execution and verbose truncation, which helps infer return shape, but it does not explicitly describe the response structure or error scenarios. Still, it is nearly complete for a list/query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'Args' section explains all 11 parameters with types, defaults, and formats (e.g., 'ISO 8601 UTC start', 'default: all directories in scope', 'ignored if date_start given'). This adds significant meaning 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Find AD objects with IoE deviances for a checker within a time window,' which is a specific verb + resource + scope statement. It clearly positions this as the time-filterable deviance query, distinguishing it from sibling tools like tie_deviances_by_checker, tie_deviances_bulk, and tie_deviances_by_directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames this as 'the time-filterable deviance query' and explains when to use hours vs. explicit date_start/date_end, implying this is the go-to for time-windowed deviance lookups. It also cross-references tie_profiles for profile selection, offering practical context, though it does not explicitly list exclusions or name alternative tools for other 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?
With no annotations provided, the description carries the full burden of disclosing the tool's behavior. It clearly states that the tool lists resources and paths, and the instruction to call it first implies it is a safe, read-only discovery operation. The context signals also confirm no parameters are needed, reinforcing that it is a straightforward listing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. The first sentence states the primary function, and the second provides usage guidance. Every word earns its place, and the information is front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no complex logic) and the presence of an output schema, the description fully covers what an agent needs to know. It explains what the tool returns (a list of resources and paths) and when to invoke it (first). The absence of side effects and the read-only nature are implied clearly enough for a catalog discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is an empty object, so there is no parameter information to clarify. The description correctly adds no parameter details because none exist. According to the rubric, a baseline of 4 is appropriate for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'all available Tenable Identity Exposure API resources and their paths', which precisely states what the tool does. It also distinguishes itself from the sibling tools by framing itself as the discovery entry point, saying 'Call this first to discover what resources exist before using other 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Call this first to discover what resources exist before using other tools.' This clearly indicates the intended usage context. However, it does not mention any exclusions or alternative scenarios, so it stops short of 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 burden. It discloses that there is no date filter, that it returns full detail, and that verbose=False drops giant attribute values and renders descriptions – concrete behavior 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A one-line summary is followed by a tidy Arg list with each parameter on its own line. No redundant filler; all lines add semantic value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the tool's purpose and all parameters, but since there is no output schema, it doesn't describe the shape of the returned deviance items or error handling. The absence of explicit alternative-tool guidance leaves a small gap in the overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args block explains all five parameters, including page being 1-based, per_page as results per page, verbose behavior, and pointers to resource schemas. Since the schema itself has no descriptions, this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List IoE deviances for a specific directory', providing a clear verb and scoped resource. 'Full detail, no date filter' adds behavioral scope and differentiates it from siblings like tie_deviances and tie_deviances_by_checker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states this is for a specific directory, which implies the primary use case. However, it doesn't explicitly name alternative tools or state when not to use it, so it misses exclusionary 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 full burden. It discloses that results are merged and sorted newest-first, timestamps are UTC, alerts are enriched, and truncation is reported. It does not explicitly state read-only behavior, but given the retrieval nature, it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then detailed explanation, then parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description sufficiently covers the tool's complex behavior (merging two sources, enrichment, truncation). It could be slightly more complete by hinting at the output structure, but it is adequate for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description provides all parameter meaning. Each parameter is explained with default values, behavior details (e.g., max_items truncation, verbose slimming), and context (profile_id defaults to 1, directory_ids restrict scope). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a unified recent-activity timeline of IoE alerts and IoA attacks. It answers specific user questions and distinguishes from sibling tools like tie_alerts and tie_attacks by being a merged view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (for recent activity, merging both IoE and IoA). It implies that for separate feeds, tie_alerts or tie_attacks would be more appropriate, but does not provide explicit exclusions or alternative conditions.
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 explaining behavior. It discloses key defaults (include_closed=False, limit=50, order=desc) and explains the meaning of order and the requirement of resource scoping. It does not mention pagination, auth, or error behavior, but for a read-only list tool this is reasonable. It adds value beyond the schema by describing the effect of parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a brief context paragraph with an example, and a clean list of arguments. Every sentence adds value, and the front-loaded purpose makes it easy for an agent to quickly understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no output schema, and no annotations, the description covers the necessary context thoroughly. It explains the required scoping, all parameters with defaults, and provides an example. It is complete enough for an agent to invoke the tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description fully compensates by explaining every parameter in the Args section. It clarifies resource_type values, resource_value meaning, attack_type_ids examples (DCSync, Kerberoasting), ISO 8601 for dates, and default values. This is essential and well done.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List IoA attack instances for a resource within a profile.' This clearly states the tool's function and scope, and distinguishes it from sibling tools like tie_alerts or tie_search_events that target different data. The example further clarifies the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that the TIE API requires scoping attacks to a resource and gives a concrete example with resource_type and resource_value. This provides clear context for when and how to use the tool. However, it does not explicitly mention alternatives or when not to use this tool, so it falls 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 of behavioral disclosure. It goes beyond a simple list statement by explaining the data scoping relationship and the need for explicit profile_id, which is important context. Though it doesn't explicitly say 'read-only', the listing verb and context make the safe-read behavior clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by essential context. Every sentence earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description fully covers the return fields (id+name), the reason the tool exists, and how to use the result. It tells the user exactly why they need this tool and what to do with the output, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the baseline is 4. The description adds value by explaining the significance of profile_id that consumers of this tool will use, even though it doesn't need to describe any parameters for this tool itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists security profiles with their id and name. It provides a specific verb and resource, and it stands apart from sibling tools by being the only one focused on profiles, which are foundational for other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that IoE/IoA data is scoped to a profile and that the console's selected profile is not exposed via API, so users must pass the correct profile_id explicitly to other tools. This gives clear guidance on when to use this tool and how to apply its results.
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?
Since annotations are absent, the description carries the full responsibility for behavioral disclosure. It reveals that the TIE API models this as a POST with a filter body, explains the effect of the verbose flag on token usage, and states the no-date-filter constraint. These insights go beyond what a simple 'list' would imply and are crucial for an agent to anticipate output size and API semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is concise and front-loaded, and the subsequent Args block is necessary given the schema lacks descriptions. While the text is a bit longer than minimal, every sentence earns its place—the POST body detail and verbose explanation are useful, not redundant. A slightly leaner formatting could tighten it, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description covers all critical aspects: purpose, alternatives, parameter semantics, and even output verbosity control. It does not explicitly describe the return structure, but the phrase 'List IoE deviances' and the verbose flag sufficiently imply the output format. The description is complete enough for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's Args block fully compensates by documenting all six parameters with meaningful details. It explains checker_id references the checkers resource, profile_id default, page and per_page pagination, expression as an optional filter object defaulting to {}, and verbose behavior. This adds far more value than the bare schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List IoE deviances for a given checker within a profile (full detail, no date filter).' This clearly distinguishes the tool from siblings by explicitly noting the absence of a date filter, making it immediately obvious what the tool does and how it differs from tie_deviances or tie_recent_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides alternative tools for time-bounded queries: 'For a time-bounded view use tie_deviances(hours=...) or tie_recent_activity instead.' This gives clear when-to-use and when-not-to-use guidance, along with named alternatives. It also explains that an empty expression returns all deviances, further clarifying expected usage.
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:
Score Badge
Copy to your README.md: