avanan-mcp

Server Quality Checklist

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

Latest release: v2.2.2
Disambiguation5/5
Each tool targets a distinct resource and action: events vs emails vs exceptions, with separate query/get, quarantine/restore, and CRUD operations. There is no ambiguity between tools, as their purposes are clearly differentiated.
Naming Consistency5/5
All tools follow a consistent 'hec_verb_noun' snake_case pattern. Verbs like query/get/search, quarantine/restore, and list/add/update/delete are used predictably across the tool set.
Tool Count5/5
With 13 tools, the set is well-scoped for a security email management server. It covers events, emails, quarantine actions, task tracking, and exception management without being overloaded or too sparse.
Completeness4/5
The tool surface covers querying, retrieving, quarantining, and restoring events and emails, plus full CRUD for exceptions. A minor gap is the lack of tools to update event properties (e.g., severity), but the core workflows are complete.
Average 3.6/5 across 13 of 13 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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 present, so the description carries full burden. It states 'update' implying mutation, but it does not disclose permissions, side effects, idempotency, or error handling.
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 concise sentence, but it lacks any structure (bullet points, sections) that would aid scanning. It earns its place but is not overly efficient in conveying more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, optional fields, or behavioral details of the update 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 only 8%. The description adds limited value: it mentions the entity ID and the whitelist/blacklist types, but does not explain the other 10 parameters or their matching semantics.
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 (update) and the resource (existing whitelist or blacklist entry by entity ID). It distinguishes from sibling tools like hec_add_exception and hec_delete_exception.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not include use cases, prerequisites, or 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.
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 disclosing behavioral traits. The description only states the basic operation (get details by ID) without mentioning output structure, possible errors, rate limits, or whether the event is deleted or modified. This is insufficient for a read operation with no safety 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 a single sentence with no wasted words. It includes the key elements (action, resource, identifier) and is appropriately front-loaded.
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 low complexity (1 parameter, no output schema, no annotations). In this minimal context, the description is mostly sufficient for the core purpose, but it lacks behavioral transparency and usage guidance. Given the simplicity, a score of 3 reflects that it provides the basic function but leaves the agent with unanswered questions about output and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the only parameter (eventId) is described in the schema as 'The event ID to retrieve.' The description does not add details beyond what the schema provides, but the schema itself is adequate. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('full details for a specific security event'), and identifier ('by ID'). It is distinct from sibling tools like hec_query_events (querying) and hec_quarantine_events (quarantine action), so purpose is clear and differentiated.
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. For example, it does not explain when to use hec_get_event versus hec_query_events to retrieve event details, nor does it mention prerequisites (e.g., needing the event ID from a prior search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose whether the tool is read-only, has side effects, or involves pagination (despite a scrollId parameter). There is no mention of rate limits, permissions, or what happens to results. The lack of behavioral context leaves the agent guessing.
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 at three sentences. The first sentence immediately states the main purpose, making it front-loaded. Each sentence adds useful information (search scope, filter categories, advanced filter operators). There is no redundancy or fluff, though it could be slightly more structured.
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 6 parameters and no output schema, the description lacks important context: it does not mention that startDate and saas are required, that pagination exists via scrollId, or what the response format is. It also omits the optional saasEntity filter. The description is insufficient for an agent to fully understand the tool's usage boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema: it mentions filtering by 'sender, recipient, subject, SaaS platform, and date range,' which aligns with schema fields, but does not elaborate on how to use the filters array or provide examples. It does not compensate for any gaps.
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: 'Search email and SaaS entities in Checkpoint Harmony Email.' It uses a specific verb (Search) and resource (email and SaaS entities), which distinguishes it from sibling tools like hec_get_email (retrieve single) and hec_query_events (query events). The mention of filters further narrows 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not explain why one would choose hec_search_emails over hec_get_email or hec_query_events. The filter hints are implicit usage, but no exclusions or context for decision-making are given.
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 present, so the description must disclose behavioral traits. It only states the basic function, without mentioning idempotency, rate limits, permissions, or output behavior. The agent gains no extra insight 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description omits details about the output format or pagination behavior. Since there is no output schema, the agent might need more context to understand what the returned list contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already provides a clear description for excType. The description does not add new information about parameters beyond what the schema offers.
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 'List' and resource 'whitelist or blacklist entries' in Checkpoint Harmony Email. It clearly distinguishes from sibling tools like hec_add_exception or hec_delete_exception which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description does not explain prerequisites or scenarios where listing is appropriate.
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 provided, so description must disclose behavioral traits. It only says 'Restore', which implies mutation but does not explain whether it's reversible, what permissions are needed, or if the operation is synchronous. Lacks depth.
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?
Single, concise sentence efficiently communicates core function. No wasted words, but could be slightly more informative without harming 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?
With 2 params and no output schema, the description is minimal. It does not explain return values, error handling, or async behavior. Acceptable for a simple tool, but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters adequately. Description adds no extra meaning beyond what's in the schema descriptions, meeting baseline but not exceeding.
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 clearly states the action (restore), target (specific quarantined email entities), and method (by entity ID). It distinguishes from sibling hec_restore_events by specifying 'emails'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs. alternatives. Implies use when you have quarantined email entity IDs to restore, but could mention prerequisite (e.g., IDs from search) or contrast with hec_quarantine_emails.
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 indicates a read operation but does not detail the contents of 'full details' (e.g., fields, attachments) or any side effects. With no annotations, the agent must infer safety. It is minimally adequate for a simple retrieval.
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 sentence with no superfluous words. It is appropriately concise for a tool with one parameter.
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 with no output schema, the description is mostly complete. However, it lacks information about the return structure, which would help the agent understand what 'full details' means. Sibling tools might have similar brevity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description only restates 'by its entity ID' without adding format, constraints, or examples beyond the schema's property description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'full details for a specific email entity', and the method 'by its entity ID'. It distinguishes from sibling tools like hec_search_emails that list multiple emails or hec_get_event that retrieves a different entity.
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 siblings, such as after searching for emails or before updating an exception. There is no mention of prerequisites or context where this tool is appropriate.
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 provided, so description carries full burden. Does not disclose whether the operation is read-only, non-destructive, or any side effects. Minimal behavioral info beyond basic function.
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, zero fluff, perfectly front-loaded with purpose and usage. Every sentence earns its place.
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?
Considering simplicity and single parameter, description covers purpose and usage. However, lacking output schema, it should describe the response format (e.g., status details). Adequate but with a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description reinforces the schema by explaining the origin of taskId. No additional semantics beyond what schema provides, achieving baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'check', resource 'status of an action task', and specifies the task types (quarantine/restore). Distinguishes from sibling tools by indicating it is a follow-up to quarantine or restore actions.
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 instructs to use the taskId returned by quarantine or restore tools, providing clear context for when to use this tool. No exclusions or alternatives are necessary given its specific role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It discloses that the operation returns task IDs for progress tracking, which is useful asynchronous behavior context. However, it does not mention whether the restoration is reversible, if it requires special permissions, what happens if an event ID is already restored, or any 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?
Two sentences, each earning its place: first states the action and input, second states the return value. No wasted words, perfectly front-loaded.
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 only one parameter with 100% schema coverage, no output schema, and no annotations. The description covers the core action and return value, which is near-complete for a simple restore operation. It could mention potential errors or prerequisites (e.g., events must be quarantined), but over half a dozen sibling tools exist, and this is well-defined 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by confirming that eventIds are quarantined event IDs (tying to the resource), and that multiple can be restored at once. It also clarifies the output provides task IDs, helping the agent understand the param's role and expected outcome.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Restore' and the resource 'quarantined events by event ID', which distinguishes this tool from siblings like hec_restore_emails (which likely works on email IDs) and hec_quarantine_events (the inverse operation). It also mentions returning task IDs for tracking, adding useful outcome details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after an event has been quarantined, and mentions tracking via task IDs, but does not explicitly state when to use this versus hec_restore_emails or how to follow up on task status (e.g., use hec_get_task_status). No alternative or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description indicates a read operation ('Query… Returns events') and mentions remediation actions. However, it does not disclose pagination behavior (scrollId is present but not explained), rate limits, auth requirements, or default ordering. It is adequate but lacks depth.
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 consists of two concise sentences with no wasted words. The core action ('Query… events') is front-loaded, followed by supported filters and return value. Every sentence adds value.
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 8 optional parameters, no output schema, and no annotations, the description covers the essential aspects: what it queries, filters available, and what it returns (events with remediation actions). It does not detail pagination or defaults, but for a query tool with clear schema descriptions, it is reasonably 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 100%, so each of the 8 parameters is documented. The description merely summarizes the filter types (type, state, severity, date range, SaaS platform) without adding any new semantics or constraints beyond the schema. Baseline 3 applies as the schema already does the heavy lifting.
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 a clear verb+resource: 'Query Checkpoint Harmony Email security events.' It lists example event types (phishing, malware, etc.) and specifies supported filters. This clearly distinguishes it from sibling tools like hec_get_event (single event) and hec_search_emails (emails, not 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the tool supports filtering by various criteria, which implies it should be used when needing filtered event queries. However, it does not explicitly say when not to use it (e.g., for a single event retrieval, use hec_get_event instead) or mention any alternatives. The guidance is implicit rather than explicit.
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 must carry the behavioral burden. It discloses the operation type (add to whitelist/blacklist) and required fields, but omits details like idempotency, duplicate handling, authorization needs, or side effects. 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 a single, well-structured sentence that front-loads the action and immediately provides the key usage condition. Every word earns its place; there is no redundancy or fluff.
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 11 parameters, no output schema, and no annotations. The description covers the essential requirement (match fields) but does not explain return values, optional parameter behavior, or error states. It is adequate for a basic understanding but leaves gaps for an AI agent to handle complex scenarios.
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 73%, so the schema already documents most parameters. The description adds value by grouping match fields and stating the 'at least one' constraint, but does not elaborate on the matching sub-parameters (subjectMatching, etc.) or provide additional semantics 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 action ('Add an entry') and distinguishes between whitelist and blacklist via the excType parameter. It also specifies the required match fields, making the tool's purpose unambiguous relative to siblings like hec_delete_exception and hec_update_exception.
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 a crucial usage rule: 'At least one match field must be provided.' This helps the agent understand when the tool is valid. However, it does not explicitly compare with alternatives (e.g., when to use add vs update) or state conditions for non-use, but the rule is clear enough.
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?
Adds value beyond annotations by emphasizing irreversibility and permanence. Consistent with destructiveHint.
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?
Single sentence plus warning, highly concise and front-loaded with destructive caution.
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?
Adequate for a simple destructive delete tool with two parameters and no output schema. Missing return value info but acceptable.
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 50% (excId described, excType only has enum). Description does not elaborate on parameters beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool deletes a whitelist or blacklist entry by entity ID. Distinguishes from sibling tools like add, update, list.
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?
Explicitly instructs to confirm with user before invoking, but does not provide when to use vs alternatives or exclude 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?
Annotations already mark destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds critical context: it is 'HIGH-IMPACT', affects user access, returns task IDs to track progress, and is reversible via restore. It does not contradict annotations. One minor gap: it doesn't explicitly state that action is async (task IDs 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?
At 4 sentences, it is concise but could be slightly tighter. The warning emoji and 'HIGH-IMPACT' are front-loaded. Every sentence adds value: impact, what it does, reversibility, tracking, confirmation. The last sentence about confirmation is slightly redundant with the first sentence's implication of caution.
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 is a high-impact mutation with 2 simple params and no output schema, the description adequately covers behavior. It mentions task IDs for tracking but does not explain how to interpret the response or that the operation is asynchronous. With annotations providing safety profile, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described in the schema. The description mentions 'entity ID' which maps to the required 'entityIds' parameter, but adds no extra detail about format or constraints beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Quarantine' and the resource 'specific email entities by entity ID'. It distinguishes this tool from siblings like 'hec_quarantine_events' by specifying 'email entities'. The purpose is immediate and specific.
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 'Confirm with the user before invoking', which is strong usage guidance. It also implies when to use (when quarantining is needed) and indicates reversibility via 'restore', referencing sibling restore tools. This guides the agent on decision-making.
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 high-impact nature, reversibility via restore, effect on user access, and task ID tracking. Adds significant value beyond annotations (destructiveHint=true) without contradiction.
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?
Extremely concise with two sentences, front-loading critical warnings and key behaviors. No wasted words.
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?
Fully covers the tool's operation: what it does, consequences, reversibility, and follow-up tracking. Adequate for a simple tool with one parameter and no 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 covers 100% of parameters with descriptions. The description does not add extra meaning beyond 'by event ID' and 'one or more' which is already implied by minItems=1.
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 action 'quarantine' on 'security events' by event ID. Differentiates from sibling tools like hec_quarantine_emails (different resource) and hec_restore_events (reverse operation).
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 instructs to confirm with the user before invoking, indicating high-impact context. Mentions reversibility but does not explicitly state when not to use or list alternatives.
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:

[![avanan-mcp MCP server](https://glama.ai/mcp/servers/wyre-technology/avanan-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wyre-technology/avanan-mcp)

Score Badge

Copy to your README.md:

[![avanan-mcp MCP server](https://glama.ai/mcp/servers/wyre-technology/avanan-mcp/badges/score.svg)](https://glama.ai/mcp/servers/wyre-technology/avanan-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wyre-technology/avanan-mcp'

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