eSentire Atlas MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
The major domains are cleanly separated by tickets_, ti_, findings/finding_, and mvs_ prefixes, and most tools target a distinct resource+action. The only mild ambiguity comes from near-variant tools such as findings_search vs findings_search_advanced and ti_indicators vs ti_indicators_paged vs ti_indicators_misp, but their descriptions explain the differences.
Naming Consistency4/5Most names follow a verb_noun pattern under a clear domain prefix, e.g. tickets_list_cases, mvs_get_asset, and ti_check_ip. A few deviations such as tickets_case_type_configs, mvs_asset_details, mvs_assets_affected_by, and finding_update alongside findings_search prevent a perfect score, but the style is otherwise consistent and readable.
Tool Count3/529 tools feels heavy for an MCP surface and will consume meaningful agent context, placing the server above the ideal 3-15 range. The count is partly justified by the broad eSentire platform scope spanning cases, threat intel, findings, and MVS, but it is still borderline and could reasonably be split into separate servers.
Completeness4/5The surface covers the core case lifecycle, findings search/update, threat-intel feeds, and MVS asset/vulnerability/patch workflows well. Minor gaps include no direct single-finding fetch and no support for attachments over 5MB, but agents can usually work around these using the existing search and metadata tools.
Average 3.8/5 across 29 of 29 tools scored. Lowest: 2.9/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 are provided, so the description must carry full behavioral burden. It only says 'Search ... for a date range' and 'API behind the Findings table'. It does not disclose pagination behavior, defaulting rules (though schema does), any required parameters, or what happens with missing date ranges. The schema covers many details, but the description itself adds minimal behavioral context beyond the basic intent.
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 two sentences and stays on point, stating the core purpose first. It is concise and free of fluff, though it could be slightly more informative without becoming verbose. No structural issues.
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?
Despite having a rich schema and an output schema, the description is very thin. It does not explain pagination defaults (page, per_page) even though they are mandatory upstream, nor the special interaction of assignee_email with use_v2. It also does not mention the existence of 'findings_search_advanced' or how this tool differs. This is incomplete for a tool with 9 parameters and a complex query object, even though the schema carries some weight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description mentions 'date range' which maps to start_date and end_date, but adds no additional meaning beyond that. Per the rubric, baseline is 3 when schema coverage is high, and this description does not substantially exceed that baseline.
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 states a clear purpose: 'Search eSentire Findings (detections/alerts) for a date range.' It identifies the resource (Findings) and the primary action (search) with a specific scope (date range). However, it does not differentiate from the sibling 'findings_search_advanced', so an agent cannot tell when to use this versus that tool just from the description.
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?
The description gives no explicit guidance on when to use this tool versus alternatives. It only implies that it is for searching findings by date range, but does not mention when to prefer 'findings_search_advanced' or any other tool, nor any exclusions or requirements. This leaves usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only discloses that this is a write operation via '(WRITE)', which is minimally informative and mostly restates the verb 'Update'. It does not mention side effects, idempotency, requirement for existing record, or any error conditions. For a mutation tool, this is insufficient.
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 a single, concise sentence that directly states the purpose. It is front-loaded with the action and flags the write nature. There is no wasted wording, so it earns a high score for conciseness.
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?
Given it is a write operation with a nested updates object and no annotations, the description is too sparse. It doesn't explain whether updates are partial or full, what happens if the finding doesn't exist, any permission requirements, or expected results (though an output schema exists, so return values may be covered). The description alone provides insufficient context for correct invocation and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (finding_id and updates) are fully documented in the schema, including an example for updates. The description adds no additional meaning about parameters. With high schema coverage, the baseline of 3 applies; the description neither helps nor harms.
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 verb 'Update' and the resource 'existing Finding', and explicitly flags it as a write operation with '(WRITE)'. This distinguishes it from read/search tools in the sibling list, though it doesn't specifically differentiate it from other update tools like tickets_update_case, but the resource type (Finding vs tickets) makes it unambiguous enough.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, workflows (e.g., search first then update), or conditions that make this tool the correct choice. The single sentence gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only listing operation but does not state whether it returns metadata only, whether content download is out of scope, or any auth/pagination behavior. The output schema exists but the description adds no behavioral context beyond the word '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?
A single sentence with no filler; the verb and object are front-loaded. Every word earns its place given the simple one-parameter API.
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?
For a one-parameter tool with an output schema, the basic listing intent is adequately conveyed. However, it lacks the relationship to closely related attachment tools (link, upload, delete) and uses 'case' where the parameter is a ticket, leaving agent selection slightly under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter (ticket_id, 'eSentire ticket number') with 100% coverage, so the baseline is 3. The description adds no extra parameter-level meaning and does not clarify the 'case' phrasing beyond what ticket_id states.
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?
States a specific verb ('List') and resource ('file attachments on a case'), so the operation is immediately recognizable. It is clear enough to separate from upload/delete/link siblings by operation type, but it does not explicitly differentiate from tickets_get_attachment_link, and 'case' vs ticket_id is mildly inconsistent.
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 is given about when to use this tool instead of related siblings such as tickets_get_attachment_link or tickets_list_emails. The description relies entirely on the verb to imply intent; there are no exclusions, prerequisites, or alternative routing.
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 burden of behavioral disclosure. It only says 'List', which implies a read operation, but it does not disclose pagination, sorting/filter behavior, output wrapping, or the meaning of 'sub-resource'. The schema mentions offset/limit but the description itself adds almost no 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 a single short sentence with no filler or redundancy, and it is front-loaded with the action verb. It is efficient, though it could be slightly more informative without losing conciseness.
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 input schema is complete and an output schema exists, which covers much of the mechanical detail. However, the description does not orient the agent on how this tool relates to sibling asset tools, when to use it, or what behavioral caveats apply to pagination and filters. It is minimally viable but leaves usage context to be inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter, including asset_id, resource, filters, sorts, and include_fields, already has documentation. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a clear scope ('a sub-resource of one asset'), which distinguishes it from top-level list tools like mvs_list_assets and mvs_get_asset. The sub-resource concept is somewhat generic, but the required 'resource' enum in the schema concretely defines which sub-resources are available.
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 phrase 'of one asset' implies this tool is for asset-scoped listing rather than top-level lists like mvs_list_vulnerabilities or mvs_list_missing_patches. However, the description does not explicitly state when to prefer this over sibling tools such as mvs_get_asset or mvs_get_asset_vulnerability, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 behavioral burden. It only restates the action and resource, without disclosing pagination behavior, default date scoping, read-only guarantees, or any upstream quirks. 'List' weakly implies a read operation, but that is not explicit.
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 a single concise sentence with no filler and the core action is front-loaded. It is efficient, though it could have added sibling differentiation or usage context without becoming verbose.
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 8-parameter schema, 100% parameter coverage, and presence of an output schema, the structured data already handles parameter and return semantics. However, the description lacks any usage guidance or behavioral context and does not leverage sibling relationships, leaving the agent to rely on names alone for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all eight parameters in detail. The description adds no parameter-level meaning, which is acceptable given full schema coverage; therefore the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List cases from eSentire's ticketing system.' This clearly distinguishes the tool from siblings like tickets_get_case (single case), tickets_create_case, and tickets_list_comments by naming the exact resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention that tickets_get_case is for retrieving a single case, nor any exclusions or conditions. Usage must be inferred entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose operational traits, and it does inform the agent that responses use UPPERCASE field names and that there are two parallel count families, which is valuable to prevent confusion in downstream processing. However, it does not disclose that the missing_patches_only parameter switches the endpoint to /assets-missing-patches, nor does it state the tool is read-only or mention any performance implications or side effects. The warning is helpful but coverage is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main purpose is front-loaded, and the second sentence adds a critical warning about field naming and count families in a compact form. This is highly concise and well-structured with zero wasted words.
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 output schema and parameter schema cover most details, the description misses the behavior of the missing_patches_only parameter, which switches the queried endpoint. The warning about field name casing and count families is useful, but the tool's full usage context (e.g., when to use this vs. sibling tools, endpoint behavior) is absent. Given the presence of an output schema, this is adequate but not complete for a tool with this many options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters have descriptions in the schema, giving 100% coverage, so the baseline is 3. The description itself adds no parameter-specific details, relying entirely on the schema for parameter meaning. It does not even mention the endpoint-switching behavior of missing_patches_only beyond what the param name implies.
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 lists discovered assets and their vulnerability counts, identifying both the resource and the action. However, it does not explicitly differentiate from sibling tools like mvs_list_vulnerabilities or mvs_get_asset, relying on the verb 'list' to imply a summary rather than naming what it is not.
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?
The description provides no guidance on when to use this tool versus alternatives such as mvs_list_vulnerabilities or mvs_get_asset. It only describes the output format and does not mention conditions like needing missing patches, despite the existence of the missing_patches_only parameter. There is no exclusion or mention of preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states the action without revealing any specifics such as pagination behavior, default sorting, whether full email bodies are returned, or any potential truncation. This is a significant gap for a tool that could return large payloads.
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 with no superfluous words. It communicates the essential purpose efficiently and is well-structured for quick scanning.
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 is relatively simple, and the schema covers parameter details; the output schema presumably documents return structure. However, the description provides no context about the shape of the response, typical use cases, or any caveats. It is minimally sufficient but leaves an agent relying heavily on the schema and inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema. The tool description adds no additional meaning or syntax hints beyond what the schema provides, rendering it a baseline 3. It does not harm, but it does not enhance.
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 states a specific verb ('List'), resource ('email correspondence'), and scope ('attached to a case'). It clearly differentiates from siblings like tickets_list_comments and tickets_list_attachments by specifying the subject. An agent can immediately understand what the tool does without ambiguity.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that comments or attachments have separate tools, nor does it suggest any conditions or exclusions. The purpose is clear, but the absence of contextual routing leaves the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. "Fetch" reasonably implies a read-only retrieval operation with no mutation, which is useful. However, it does not disclose anything about failure behavior, access requirements, or whether it returns raw file content or a reference, leaving some behavioral uncertainty.
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, front-loaded sentence with no unnecessary words. It clearly communicates the core purpose and the distinguishing MISP-format detail without any filler, which is ideal for a simple 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 is simple, and the output schema is present, so return values do not need to be explained in the description. However, the description does not clarify how this tool relates to sibling indicator tools, and with no annotations it misses an opportunity to provide richer operational context such as prerequisites or expected file-size limits. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters year and file_name are already fully documented in the input schema. The description adds no additional meaning about how these parameters are used or formatted. This meets the baseline of 3 but does not exceed it.
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 states a specific verb and resource: "Fetch a MISP-format indicator file from the Threat Intelligence feed." It is clear that this tool retrieves a file in MISP format, which distinguishes it from sibling indicator tools like ti_indicators and ti_indicators_paged. However, it does not explicitly contrast those siblings, so it falls just short of full differentiation.
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?
The description provides no guidance about when to choose this tool over alternatives such as ti_indicators or ti_indicators_paged. There is no mention of conditions, exclusions, or fallback tools. The MISP-format wording implies a use case, but the agent is left to infer the decision criteria.
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 disclosure burden. 'Get' clearly indicates a read-only retrieval and 'full detail' signals the expected response granularity. Still, no additional behavioral context such as error handling, permissions, or 404 behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six words, front-loaded with the action and target, and contains no filler. Every word earns its place.
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?
For a single-parameter get operation with an output schema, the description gives the essential call contract. However, the presence of mvs_asset_details in the sibling list creates ambiguity about which tool to use for asset details, and the description does not resolve that ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, asset_id, is already described as 'The asset's UUID.' The description adds no extra parameter meaning, but the schema is sufficient on its own, so the baseline of 3 applies.
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 states a clear verb ('Get'), a clear resource ('asset'), and a singular scope ('one asset'). It does not differentiate itself from the sibling tool mvs_asset_details, whose name suggests the same operation, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one asset' implies this is the tool to use when a specific asset ID is known and full details are needed. However, it offers no explicit guidance about when to prefer this over siblings like mvs_asset_details or mvs_list_assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the operation ('Get') without mentioning side effects, permissions, error behavior, or special conditions (e.g., whether the asset must be affected). The output schema exists, but the description does not clarify behavioral traits like idempotency or data safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is concise and front-loaded, stating exactly what the tool does without 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?
The description is adequate for a simple get operation given the output schema and documented parameters, but it lacks guidance on use cases and differentiation from similar tools (e.g., mvs_get_vulnerability). An agent could invoke it correctly, but might not know when to prefer it over siblings or what the output represents beyond schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters documented in the input schema (asset_id as 'The asset's UUID.', vulnerability_id as 'The vulnerability identifier.'). The description does not add any extra meaning to the parameters, so it meets the baseline for high schema 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 purpose is clear: verb 'Get', resource 'one vulnerability', scope 'as it applies to one specific asset'. This distinguishes it from siblings like mvs_get_vulnerability (likely asset-agnostic) and mvs_list_vulnerabilities (list), making it evident this is a targeted single-pair query.
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 a specific vulnerability in relation to a specific asset, but it does not explicitly contrast with alternatives such as mvs_get_vulnerability or mvs_assets_affected_by, nor does it state when not to use the tool. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden but only says 'List'; it does not disclose pagination, the software_only endpoint switch, filtering semantics, or any side effects. The schema mentions software_only, but the description itself adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with the key scoping qualifier 'across the whole estate' front-loaded; there is no filler, redundancy, or restatement of the tool name.
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 schema is rich and includes an output schema, so parameter details and return shape are covered. Still, the description alone leaves an agent without guidance on selecting this over closely related vulnerability tools or on the software_only distinction, making it minimally viable rather than comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents limit, sorts, offset, filters, software_only, and include_fields. The description adds no parameter-specific meaning, but it does not need to because the schema fully carries that weight.
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 ('List') and a clear resource ('vulnerability catalogue') with an explicit estate-wide scope. This makes it easy to distinguish from sibling get/asset-scoped tools such as mvs_get_vulnerability and mvs_list_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across the whole estate' implies this is for unqualified, estate-wide enumeration rather than a single vulnerability or asset. However, it never states when to prefer this over mvs_get_vulnerability, mvs_list_missing_patches, or related search tools, and offers no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only operation via the word 'check', but does not explicitly state non-modification, error behavior, or potential rate limits. The minimal nature provides some clarity but leaves room for 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 sentence with the action and target front-loaded. There is no extraneous detail, and it is immediately actionable.
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?
For a simple lookup with one documented parameter and an output schema available, the description is functionally complete. The main gap is the lack of usage differentiation among siblings, but the tool's simplicity reduces the risk of misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'ip' (IPv4 or IPv6 exact match). The description adds no additional meaning beyond the schema, which already covers the format and matching criterion. Baseline of 3 is appropriate when schema coverage is complete.
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 states a clear verb (check), a specific resource (IP address), and the target context (eSentire IP Watch blocklist). It differentiates its purpose from the sibling ti_ipwatch tool, which likely manages the list, by focusing on a single lookup action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as ti_ipwatch or ti_indicators. While the purpose implies a read-only check, it does not state exclusions or preferred conditions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Get' clearly indicates a read operation, and 'in full' suggests the return scope, but it does not disclose behaviors like not-found handling, permissions, or how 'full' relates to the 'fields' restriction parameter.
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?
Five words, front-loaded, and free of filler. Every word contributes to understanding what the tool does.
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?
The tool is simple, has an output schema, and the parameter schema is complete, so the minimal description is mostly sufficient. A small gap remains: it does not clarify the interplay between 'in full' and the 'fields' column restriction, nor explicitly route users away from sibling list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage with meaningful descriptions: 'ticket_id' includes an example and 'fields' explains column restriction. The description itself adds no parameter-specific meaning beyond the baseline.
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 uses a specific verb and resource ('Get one case') and the qualifier 'in full' distinguishes it from list/create/update case tools. It is clear but does not explicitly name sibling tools or define what 'full' encompasses.
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?
Usage is implied: 'Get one case' suggests use when a single case's full data is needed, contrasted with 'tickets_list_cases' for multiple cases. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. 'Get details' reasonably implies a read operation, but the description does not disclose behavior like not-found handling, what happens when both identifiers are provided, or whether at least one identifier is required.
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, front-loaded sentence with no filler or repetition. Every word contributes directly to identifying the tool's purpose and lookup modes.
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?
The tool is simple, the output schema exists, and the parameter schema is thorough. However, both parameters are optional by schema, and the description does not explicitly state that at least one identifier must be supplied, which is a small but real completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes both parameters, including that cve_id takes precedence. The description's mention of 'by internal id or by CVE' adds no meaningful meaning beyond what the schema already states, so baseline 3 is appropriate.
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 resource ('details for one vulnerability'), and further specifies the two lookup keys ('by internal id or by CVE'). The word 'one' clearly differentiates it from list-style siblings like mvs_list_vulnerabilities.
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 intended context is implied: use this tool when you need a single vulnerability's details and already have an internal ID or CVE. However, it does not explicitly mention alternatives or when to prefer mvs_list_vulnerabilities or mvs_get_asset_vulnerability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals an important behavior: 'an unresolvable location is silently dropped,' which is significant hidden behavior. It does not detail pagination or read-only semantics, but the action verb and failure-mode disclosure give useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the primary action front-loaded and a single relevant behavioral caveat. Every sentence earns its place, and there is no filler.
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?
This is a simple list tool with two optional parameters and an output schema available, so the description covers the essential behavior plus the key silent-drop caveat. It relies on prior knowledge of the contacts tool for full context, but that reference is reasonable given the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters, limit and offset, with clear descriptions, giving 100% schema description coverage. The tool description does not add parameter-level meaning, so it stays at the baseline for fully schema-covered parameters.
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 and resource: 'List locations registered for your account.' It clearly distinguishes this tool from siblings by naming the location resource and account scope, and the reference to contacts signals the analogous counterpart.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. The 'Same rationale as contacts' note explains behavior but does not indicate selection criteria or exclude other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It identifies the operation as a search (read-oriented) and mentions the POST mechanism, but does not describe response shape, pagination, or error behavior. The output schema likely covers some of this, but the description itself is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the key differentiator ('POST variant') and the use case. No wasted words; every element earns its place.
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?
For a simple pass-through tool with one parameter and an output schema, the description adequately supports selection and invocation. It could mention the target endpoint or expected response, but the schema and output schema fill most remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema documents that the body is passed through verbatim. The description adds no extra parameter semantics beyond implying the body contains filters. Baseline 3 is appropriate since the schema does the heavy lifting.
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 identifies this as a POST variant of the Findings search, with a specific distinguishing condition: filter payloads too large for a query string. It implicitly distinguishes itself from the sibling findings_search tool by contrasting the transport method.
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 states when to use this tool: when filter payloads are too large for a query string. It does not explicitly name findings_search as the alternative, but the contrast is strongly implied by 'variant of the Findings search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It establishes a non-mutating list operation and the estate-wide scope, which is useful, but it does not disclose pagination behavior, aggregation, or any performance implications. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler. It states the verb, resource, and scope in immediate order, making it easy for an agent to scan and understand.
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 the tool's low complexity, fully described parameters, and presence of an output schema, the description is largely sufficient for selecting and invoking the tool. It lacks explicit alternative routing, but that is a minor gap for a read-only listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (limit, sorts, offset, filters, include_fields) are already fully documented. The description adds no parameter-level meaning beyond the overall scope, matching the baseline for high schema 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 ('List'), names the exact resource ('missing patches'), and defines scope ('across the whole estate'). This clearly distinguishes it from sibling tools like mvs_list_vulnerabilities, mvs_list_assets, and per-asset operations.
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 phrase 'across the whole estate' gives clear context for when to use this tool: for estate-wide missing-patch discovery rather than asset-specific or vulnerability-specific queries. It does not explicitly name alternatives or exclusions, but the scope is clear enough to route an agent correctly.
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?
There are no annotations, so the description carries the behavioral burden. It does disclose the WRITE nature and the size constraint, but it does not describe what happens on success, whether the upload is synchronous, permission requirements, or overwrite behavior. The output schema exists but its contents are not shown, so return-value behavior remains unspecified.
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?
Two concise sentences that front-load the core purpose and immediately state the key constraint. Every sentence earns its place, and there is no redundant restating of schema details.
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?
The description captures the essential calling constraint (inline path, <=5MB) and the schema covers all parameter semantics. It is reasonably complete for a simple one-shot upload tool, though it leaves some behavioral details like failure modes and response shape unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains ticket_id, file_name, content_base64, and username. The description adds the 5MB inline-path limit, which is useful context, but it adds no additional meaning to individual parameters beyond what the schema provides.
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?
States a specific action ('Attach a file to a case') and marks it as a WRITE operation. This clearly distinguishes it from sibling tools like tickets_list_attachments, tickets_get_attachment_link, and tickets_delete_attachment. The scope is unambiguous enough for an agent to know what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the supported inline path and the 5MB size boundary, and tells the agent that larger files require a different presigned-upload flow outside MCP. It does not name a sibling MCP alternative, but since the alternative requires a real filesystem, the exclusion is still practical and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself; it does that by explaining hourly upstream refresh and identical results within the cache window. It also states the indicator categories. It doesn't discuss rate limits or response size, but that is a minor gap for a read-only fetch.
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 purpose is front-loaded and the coverage and caching behavior are compressed into a short second section. Every sentence adds useful operational information 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?
For a simple fetch tool with one optional, fully documented parameter and an output schema, the description covers the core operational facts: scope, feed curation, refresh cadence, and cache behavior. It could mention how it relates to the paged/MISP variants, but that is not necessary for a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, summarize, is fully described in the schema, including its two modes and default behavior. The main description doesn't add parameter-level detail, but at 100% schema coverage the baseline is appropriate.
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?
States an explicit verb ('Fetch') and a specific resource ('most recent Indicator Bundles from the Threat Intelligence feed'), then enumerates the indicator types covered. This clearly distinguishes it as the default recent-bundle retrieval endpoint among the TI siblings.
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 gives context about freshness and caching but never tells the agent when to prefer this tool over ti_indicators_paged or ti_indicators_misp. There are no explicit exclusions or alternative conditions, so an agent must infer selection from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly states the return format ('newline-delimited list') and the data semantics ('malicious IP addresses'). It does not discuss list size or truncation, but the schema's max_entries parameter covers that aspect, and the operation is a simple read-style fetch.
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?
Two tightly written sentences with no filler. The first states the action and resource; the second states the return format and intended use. Every sentence earns its place.
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?
For a simple fetch tool with optional filters, an output schema, and no required parameters, the description covers the source, return format, and common consumption pattern. It does not mention edge cases like empty results or custom output limits, but the schema and output schema fill most of those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents contains and max_entries clearly. The description adds no parameter-level detail beyond that, which is acceptable under the baseline for full schema coverage.
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 names a specific resource ('the eSentire IP Watch blocklist') with a clear verb ('Fetch'). The mention of a newline-delimited list of malicious IPs and firewall/WAF use differentiates it from sibling tools like ti_check_ip and ti_indicators, though it does not explicitly contrast them.
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 a clear usage context: the output is 'suitable for pushing into a firewall or WAF blocklist.' This tells the agent when to reach for this tool, though it does not mention exclusions or point to alternatives for single-IP lookups or general indicator searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly flags the operation as a WRITE and notes that it is not reversible, which is critical for a destructive delete action. It does not mention permissions or side effects, but the core irreversible behavior is clearly 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 one concise sentence that front-loads the core action and includes the crucial irreversibility warning. Every word earns its place, and there is no redundant filler.
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 two-parameter delete operation with a 100%-documented schema and an output schema, the description is complete. It states the action, the scope, and the key behavioral warning, so an agent has what it needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters already have meaningful descriptions: file_uid references tickets_list_attachments and ticket_id identifies the eSentire ticket. The tool description adds no parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete'), a resource ('attachment'), and a container ('case'), which clearly differentiates it from sibling tools like tickets_upload_attachment, tickets_list_attachments, and tickets_get_attachment_link. The purpose is immediately understandable.
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 action is clear enough that an agent can infer when to call it, but the description does not explicitly state when not to use it or point to alternatives. It lacks exclusions or comparison to related attachment tools, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 of behavioral disclosure. "Find" clearly implies a read-only query, and the exclusivity constraint is stated, but the description does not disclose pagination behavior, what happens when no identifier is supplied, or whether results are limited by other implicit filters. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. The core action is front-loaded, the blast-radius metaphor adds useful framing, and the invocation rule is stated directly. Every sentence earns its place.
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 the output schema exists and the input schema covers 100% of the parameters, the description does not need to explain return values or field semantics. It provides the one piece of context the schema alone lacks: how to choose and combine the identifier parameters. It is complete enough for correct invocation, though it could briefly note that combining identifiers is disallowed.
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 100%, so the individual parameters are already described. The description adds valuable selection semantics beyond the schema by stating that exactly one of cve_id, vulnerability_id, or the patch_name/patch_type pair must be supplied. This helps an agent avoid invalid combinations that the nullable schema alone does not make obvious.
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 action and resource: "Find every asset affected by a given CVE, vulnerability, or missing patch." It reinforces this with the blast-radius framing, making it clear this is the impact/query tool rather than a generic asset or vulnerability lister. Even without naming a sibling, the "given one finding, what is exposed?" phrasing distinguishes it from sibling tools like mvs_list_assets or mvs_get_vulnerability.
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 a clear use case: "This is the blast-radius question: given one finding, what is exposed?" It also tells the agent the key invocation rule: "Supply exactly one of cve_id, vulnerability_id, or the patch_name/patch_type pair." It does not explicitly name alternatives or exclusions, but the context is strong enough to route the agent to this tool for affected-asset queries.
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 size-dependent behavior, the JSON-only request behavior, and the reasoning that binary content is not useful over MCP. This is meaningful transparency beyond the schema, though it does not cover aspects like error handling or authentication expectations.
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 front-loaded with the core purpose. The additional sentences about size limits and JSON formatting earn their place by explaining behavior an agent needs to know before calling the tool. There is no filler or redundant restating of the schema.
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?
For a read-oriented attachment fetch tool with an output schema available, the description covers the main behavioral quirk (size-based response format) and the MCP-specific constraint. It does not mention possible failure modes or authentication requirements, but those are less critical given the schema and the straightforward get-like nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description itself does not explain parameters. The size-based behavior is relevant to the unzip parameter, and file_uid is sourced from tickets_list_attachments, but both are already documented in the schema. The description adds context rather than parameter-level detail.
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: 'Fetch metadata or a download link for an attachment.' It also clarifies that raw bytes are not returned, which separates it from file-transfer or upload/download sibling tools. This gives an agent enough to know what the tool is for without inspecting the schema.
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 behavioral context: attachments under 5MB may be returned inline, while larger ones produce a cloud-storage link. It also explains that the tool always requests JSON, so callers should expect metadata or a link rather than binary content. It does not explicitly name alternatives or state when to prefer this over tickets_list_attachments, but the usage context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description still conveys the key behavioral fact: this is the endpoint that retrieves the full comment set beyond the 5 embedded on the case. It implicitly marks the operation as read-only ('List'), and the truncation caveat gives the agent meaningful expectations about what it returns.
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?
Two sentences, each earning its place: the first states the action and resource; the second supplies the essential reason this tool exists. No filler or restatement of the schema.
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?
The description is complete for a simple paginated list tool: output schema, full parameter docs, and the useful distinction from the case object's comment field are all present. An agent has enough to select and invoke it correctly without further investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already documented (ticket_id, limit, offset, fields), so the description need not add parameter details. The mention of 'the rest' lightly ties to limit/offset but adds no semantic value beyond the schema.
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 opening sentence uses a specific verb and resource ('List all comments on a case'), stating exactly what the tool returns. The second sentence distinguishes it from the case object's embedded comments ('latest 5'), so it is not confused with a case-fetching sibling.
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 gives a clear condition: the case object only carries the latest 5 comments, so use this tool for the remaining ones. It does not name the sibling tool explicitly (e.g., tickets_get_case), but the alternative and the deciding condition are identifiable.
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 clearly signals a read-only list operation and adds a non-obvious behavioral warning: unresolvable contacts are silently dropped rather than rejected in the downstream create-case call. This is genuinely useful context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the action, and every sentence contributes: the first states what the tool does, the second explains why and when to use it, including a critical warning.
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 list tool with two optional pagination parameters, full schema coverage, and an output schema, the description is complete. It even includes workflow-specific context around silent contact rejection, which is exactly the kind of insight an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with a 100% description coverage, including the upstream default for limit. The description does not add parameter-level detail, so the baseline score applies.
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 states a specific verb and resource: 'List authorised contacts for your account.' It also distinguishes its purpose by tying it directly to tickets_create_case, so an agent can immediately tell this is the contact lookup tool rather than a generic list tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use this tool: before tickets_create_case, to obtain an exact contact value. It does not explicitly name alternatives or state when not to use it, but the create-case workflow guidance is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clearly discloses that this is a write operation and adds valuable state semantics: resolving is reversible while closing is not. This goes beyond what the schema provides, though it doesn't cover permissions or side effects in more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main operation is front-loaded, and the irreversibility warning is placed precisely where it adds decision value.
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 two-parameter write tool with a high-coverage schema and an output schema, this description is complete. It explains what the tool does, what kinds of updates are expected, and warns about the one risky behavior. Nothing essential is missing.
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 100%, so the baseline is 3. The description adds semantic grouping beyond the schema by telling the agent what kinds of updates are intended: comments, customer fields, and resolution. This helps interpret the free-form 'updates' object and signals that 'resolve' is a supported state change.
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?
States a specific verb and resource ('Update a case') and enumerates exact operations: adding comments, setting customer fields, and resolving. The '(WRITE)' marker and 'case' target distinguish it from read-only sibling tools and from tickets_create_case.
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 when to use it: you have an existing case and need to modify it. It also gives useful intra-tool guidance ('Prefer resolve'), but it does not explicitly name alternatives or state when not to use this tool, such as using tickets_get_case or tickets_list_comments for read-only needs.
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. It discloses a critical behavioral trait: the taxonomy changes without notice, so the tool must be consulted fresh each time. It does not describe the output structure, but the output schema exists (signaled by 'has output schema: true'), so that is covered. The warning about rejection adds valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the primary action; the second adds essential usage guidance with a rationale. No filler, and the key usage note is front-loaded.
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 config-listing tool, the description is complete: purpose, when to use, and the danger of not using it are all covered. The output schema covers return details, and the single optional parameter is fully documented. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the case_type parameter with examples and a default. The description does not add any new parameter-level meaning, so a baseline of 3 is appropriate given that the schema handles it well.
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 explicitly states the tool lists valid case_type/case_subtype/service combinations, which is a specific verb+resource. This is clearly distinct from siblings like tickets_create_case or tickets_list_cases, and the phrase 'Always call this before creating a case' reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Always call this before creating a case.' It also explains why this is necessary—the server-driven taxonomy changes without notice, so hardcoding leads to rejected creates—subtly implying when NOT to rely on hardcoded values. This is excellent contextual routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses that this is a write operation, reaches the real SOC, creates a genuine support case, and warns that invalid combinations are rejected. This is exactly the high-impact behavioral information an agent needs before invoking a mutating 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?
Four short, purposeful sentences. The most critical fact ('WRITE -- reaches the real SOC') is front-loaded, followed by the human-confirmation warning and the validation prerequisite. Every sentence earns its place, and there is no redundant or filler content.
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 15-parameter schema with 100% coverage and an output schema present, the description covers the remaining non-obvious context: real-world impact, need for human confirmation, and the requirement to validate against tickets_case_type_configs first. An agent has everything necessary to decide whether and how to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some semantic guidance by naming case_type, case_subtype, and service in the validation instruction, but it does not add new meaning or formatting details beyond what the schema already documents. It is sufficient but not exceptional.
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?
Description states the exact operation: 'Create a new case in eSentire's ticketing system.' It is clearly a create action, which distinguishes it from sibling tools like tickets_update_case or tickets_list_cases. The parenthetical 'WRITE -- reaches the real SOC' reinforces the resource and impact without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: confirm intent with a human before calling, and validate case_type/case_subtype/service against tickets_case_type_configs first. It does not explicitly name alternatives or state when not to use it beyond the human-confirmation caveat, but the 'create new' framing plus the validation instruction is strong practical 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?
There are no annotations, so the description carries the transparency burden. It discloses that the tool is a paging mechanism meant to avoid response ceiling issues, and it mentions the summarize behavior (compact indicator list vs. raw STIX). This is sufficient for a simple read-oriented pagination tool, even though it does not explicitly state side-effect-free 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?
Two short sentences with no filler. The primary action is front-loaded, and the key differentiator from ti_indicators is placed immediately after. Every sentence adds value.
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 straightforward pagination tool with three self-explanatory parameters, full schema coverage, and an output schema, the description is complete. It explains the intended use case, the main behavioral constraint (response ceiling), and the key output option (summarize), leaving no critical gap for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents limit, offset, and summarize. The description reinforces the paging intent but adds little beyond what the schema provides, except context about walking the whole feed and response ceiling.
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 verb 'Page through' and the resource 'Indicator Bundles from the Threat Intelligence feed.' It also distinguishes itself from the sibling ti_indicators by explaining when to use it ('instead of ti_indicators when you need to walk the whole feed'), so an agent can tell the two apart.
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 names the alternative ti_indicators and provides a specific condition for using this tool: when the agent needs to walk the whole feed without exceeding the response ceiling. This is direct, actionable guidance with no reliance on inference.
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:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/omichelbraga/esentire-atlas-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server