Enables management and monitoring of VMware data protection within Cohesity, allowing users to list protection sources, manage backup groups, and oversee recovery tasks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-cohesity List any protection groups that failed their last backup"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Cohesity DataProtect, providing AI assistants with full access to backup management, recovery operations, and data protection monitoring through the Cohesity REST API.
14 tools across six categories:
Tool | Description |
| Get cluster name, ID, software version, and node count |
| Get storage capacity (used/total) and throughput statistics |
Tool | Description |
| List all data protection policies with schedule and retention settings |
| List protection groups (backup jobs) with status, schedule, and last run info |
| Get detailed configuration of a specific protection group |
| Trigger an on-demand backup run for a protection group |
Tool | Description |
| List recent backup runs with status, duration, and data size |
| Get detailed information about a specific backup run |
Tool | Description |
| List all registered sources (vSphere, Physical, NAS, SQL, etc.) |
| Get full object hierarchy details for a specific source |
Tool | Description |
| List recovery tasks with status and type |
| Get detailed information about a specific recovery task |
Tool | Description |
| List cluster alerts filtered by severity, category, and state |
| Mark an alert as resolved with resolution notes |
Related MCP server: Commvault MCP Server
git clone git@github.com:fredriksknese/mcp-cohesity.git
cd mcp-cohesity
npm install
npm run buildThe server is configured via environment variables:
Variable | Required | Default | Description |
| Yes | — | Cohesity cluster hostname or IP address |
| Yes | — | Username for authentication |
| Yes | — | Password for authentication |
| No |
| Authentication domain |
| No |
| Accept self-signed SSL certificates |
Add to your claude_desktop_config.json:
{
"mcpServers": {
"cohesity": {
"command": "node",
"args": ["/absolute/path/to/mcp-cohesity/dist/index.js"],
"env": {
"COHESITY_CLUSTER": "your-cohesity-cluster.example.com",
"COHESITY_USERNAME": "admin",
"COHESITY_PASSWORD": "your-password",
"COHESITY_DOMAIN": "LOCAL"
}
}
}
}Add to your Claude Code MCP settings:
claude mcp add cohesity -- node /absolute/path/to/mcp-cohesity/dist/index.jsSet the required environment variables before running, or configure them in your MCP settings.
Once connected, you can ask your AI assistant things like:
"Show me the current cluster storage utilization"
"List all protection groups that failed their last backup"
"Trigger an on-demand backup for the VM production group"
"What are the critical alerts on the cluster right now?"
"Show me all backup runs in the last 24 hours"
"List all VMware protection sources registered on the cluster"
"Get the details of the last backup run for protection group ID 12345"
"Resolve alert ID abc123 — disk was replaced"
"What recovery tasks are currently running?"
"List all protection policies and their retention settings"
npm run dev # Run with tsx (auto-reloads)
npm run build # Compile TypeScript to dist/
npm start # Run compiled outputsrc/
├── index.ts # Entry point — creates MCP server + STDIO transport
├── cohesity-client.ts # HTTP client with token-based auth and V1/V2 API support
└── tools/
├── cluster.ts # Cluster info and stats (2 tools)
├── protection.ts # Protection policies and groups (4 tools)
├── runs.ts # Backup run management (2 tools)
├── sources.ts # Protection source management (2 tools)
├── recovery.ts # Recovery task management (2 tools)
└── alerts.ts # Alert management (2 tools)This server uses two Cohesity API versions:
V2 API (/v2/) — Used for protection groups, runs, sources, and recoveries
V1 API (/irisservices/api/v1/public/) — Used for alerts and source hierarchy
Authentication uses the V2 sessions endpoint (POST /v2/users/sessions) with Bearer token auth. Tokens are automatically refreshed on expiry.
Node.js 18+
Cohesity DataProtect cluster with REST API access (tested with Cohesity 6.x+)
SEE LICENSE IN LICENSE
Get Cohesity cluster information including name, ID, software version, and node count
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explicitly lists the return fields and implies a read-only operation with 'Get'. Without annotations, it adequately covers the tool's behavior, though it could mention that no side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant words, directly conveying the tool's action and outputs. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the return fields appropriately. It could explicitly state that no input is required, but overall complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% by default. The description adds no parameter info but doesn't need to; baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get Cohesity cluster information' with specific fields (name, ID, software version, node count), making the purpose unambiguous and distinguishing it from sibling tools like get_cluster_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While the zero-parameter call is straightforward, the description does not mention exclusions or alternative tools for specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Cohesity cluster storage and throughput statistics including used/total capacity and data throughput
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 accurately indicates a read operation fetching statistics, but does not disclose any additional constraints, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose without extraneous information. Every word is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is fairly complete, specifying the type of statistics retrieved. However, the absence of an output schema and lack of detail on the exact return format leave some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, making schema description coverage 100%. The baseline is 4; no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'cluster statistics', and specifies the included metrics (used/total capacity, data throughput). It distinguishes from siblings like get_cluster_info, which likely provides general cluster information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving stats, but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_cluster_info) or any conditions that warrant its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Cohesity protection group including configuration, schedule, and last run status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Protection group ID | |
| include_last_run_info | No | Include information about the last backup run |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It states it gets details but does not mention that it is a read-only operation, any potential side effects, or performance considerations. The description adds minimal transparency beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with 15 words, no redundant information. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, one required) and no output schema, the description covers key return content (configuration, schedule, last run status). It lacks details on error handling or edge cases, but is largely complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds context by mentioning 'last run status', which relates to include_last_run_info, but does not elaborate on parameter meaning or usage beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'protection group', and specifies what details are included (configuration, schedule, last run status). It distinguishes itself from sibling tools like list_protection_groups (which lists multiple groups) and get_protection_run (which targets runs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_protection_groups or run_protection_group. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Cohesity backup run including per-object status and statistics
| Name | Required | Description | Default |
|---|---|---|---|
| protection_group_id | Yes | Protection group ID the run belongs to | |
| run_id | Yes | Run ID to retrieve details for | |
| include_object_details | No | Include per-object backup details (can increase response size) |
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 correctly indicates a read operation ('Get detailed information') and mentions the specific data it returns (per-object status and statistics). This is sufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, directly stating the action and scope without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description could elaborate on the return structure. It hints at per-object status and statistics but does not specify the exact fields or format. Adequate for a simple retrieval tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 3 parameters with descriptions (100% coverage). The description adds value by linking 'per-object status' to the include_object_details parameter but does not provide significant additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves detailed information about a specific Cohesity backup run, including per-object status and statistics. This distinguishes it from sibling tools like list_protection_runs which list runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting detailed info on a specific run but does not explicitly state when to use this tool over alternatives like list_protection_runs. No exclusion criteria or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Cohesity recovery task including per-object restore status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recovery task ID to retrieve details for | |
| include_tenants | No | Include tenant information in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It implies a read-only operation with 'get' and adds detail about 'per-object restore status', but does not mention authentication, error handling, or potential side effects. Adequate but with gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with purpose and contains no extraneous words. It is concise and structured effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description partially compensates by mentioning 'per-object restore status', but it does not describe the response format or other fields. For a simple tool with few parameters, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description does not add additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'detailed information about a specific Cohesity recovery task', and adds specificity with 'including per-object restore status'. This distinguishes it from sibling tools like list_recovery_tasks and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., list_recovery_tasks) or any prerequisites. It lacks explicit context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Cohesity protection source including its object hierarchy
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Source ID to retrieve details for | |
| environment | No | Environment type of the source (e.g., kVMware, kPhysical, kNas) | |
| include_entity_permission_info | No | Include entity permission information |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, permissions required, or data volume. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the core purpose without extra words, achieving good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 parameters, no output schema), the description is minimally adequate but lacks details on return values or parameter relationships.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (100% coverage). The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific Cohesity protection source' and mentions 'including its object hierarchy', which distinguishes it from sibling tools like list_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific source ID is known, but does not explicitly state when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Cohesity cluster alerts with severity, description, and resolution status
| Name | Required | Description | Default |
|---|---|---|---|
| alert_states | No | Filter by alert state (default: open alerts only) | |
| alert_severities | No | Filter by severity level | |
| alert_categories | No | Filter by alert category | |
| start_date_usecs | No | Filter alerts created after this Unix timestamp in microseconds | |
| end_date_usecs | No | Filter alerts created before this Unix timestamp in microseconds | |
| max_results | No | Maximum number of alerts to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral details. It only says 'list', implying read-only, but fails to mention pagination, default filters (e.g., open alerts), or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no fluff. While concise, it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description lacks details on return format, sorting, or limitations. It does not cover pagination or the default max_results behavior highlighted in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are fully described in the schema (100% coverage). The tool description adds no extra meaning beyond what the schema already provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Cohesity cluster alerts' with a specific verb and resource. It mentions included fields (severity, description, resolution status), but does not differentiate from sibling tools like resolve_alert or other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No context on prerequisites, filters, or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Cohesity protection groups (backup jobs) with status, schedule, and last run information
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter protection groups by name (partial match) | |
| environment | No | Filter by environment type (e.g., kVMware, kPhysical, kNas, kSQL) | |
| is_active | No | Filter by active/inactive state | |
| is_paused | No | Filter by paused state | |
| max_results | No | Maximum number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It does not disclose whether the operation is read-only, whether pagination applies, or what the response format looks like. The agent cannot infer safety or limitations beyond the listed output fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is adequate but incomplete. It does not explain pagination behavior, response format, or default ordering, which are important for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have descriptions in the schema (100% coverage), so the description does not need to add detail. However, the description adds no additional context beyond what the schema provides, such as default sorting or interaction between filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'Cohesity protection groups (backup jobs)', and includes what information is returned (status, schedule, last run). It distinguishes from sibling tools like get_protection_group (single group) and list_protection_runs (runs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for overview of protection groups but does not explicitly state when to use this tool versus alternatives like get_protection_group for detailed info or list_protection_runs for runs. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Cohesity data protection policies including schedule, retention, and replication settings
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter policies by name (partial match) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly indicates this is a read-only listing operation, which is appropriate. However, since no annotations are provided, it would benefit from mentioning any potential performance implications or limits, but as a simple list, the current transparency is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys all essential information without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one optional parameter, no output schema, and no annotations, the description adequately explains the tool's purpose and output. It could mention pagination or result limits, but overall it is sufficiently complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a clear description for the single optional 'name' parameter. The description does not add any additional meaning beyond the schema, so with 100% schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'protection policies', and specifies that it includes schedule, retention, and replication settings. This effectively distinguishes it from sibling tools like list_protection_groups or list_protection_runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only states what the tool does, leaving the agent to infer appropriate usage context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent backup runs for a Cohesity protection group with status, duration, and data size
| Name | Required | Description | Default |
|---|---|---|---|
| protection_group_id | Yes | Protection group ID to list runs for | |
| run_types | No | Filter by run type | |
| local_backup_run_status | No | Filter by run status | |
| start_time_usecs | No | Filter runs that started after this Unix timestamp in microseconds | |
| end_time_usecs | No | Filter runs that ended before this Unix timestamp in microseconds | |
| max_results | No | Maximum number of runs to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states the tool lists runs with fields, omitting details like read-only nature, pagination, ordering, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 14 words is concise but lacks structure. It omits important information like filtering options or output format, making it somewhat underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 sibling tools and no output schema, the description is too minimal. It doesn't describe return format, ordering, or how it differs from get_protection_run, leaving gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds only the vague term 'recent', which provides minimal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'recent backup runs' for a protection group, specifying included fields (status, duration, data size). This distinguishes it from sibling tools like get_protection_run or list_protection_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_protection_run for a single run, run_protection_group for initiating). The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Cohesity recovery tasks with status, type, and progress information
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter recovery tasks by status | |
| environments | No | Filter by source environment type | |
| start_time_usecs | No | Filter tasks created after this Unix timestamp in microseconds | |
| end_time_usecs | No | Filter tasks created before this Unix timestamp in microseconds | |
| max_results | No | Maximum number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states the tool lists tasks with basic fields. It does not mention pagination, authorization needs, rate limits, or what happens without filters. The default max_results is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 10 words, no redundancy. It is front-loaded with purpose. However, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema or annotations, the description is too sparse. It omits important context like default results, ordering, time filter expectations, and pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds only that the tool returns 'status, type, and progress', which is generic. With full schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List', the resource 'Cohesity recovery tasks', and the information returned ('status, type, and progress'). This distinguishes it from siblings like 'get_recovery_task' (singular) and other listing tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While siblings like 'get_recovery_task' handle individual tasks, the description does not mention this or provide any when/not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered Cohesity protection sources such as vSphere, Physical servers, NAS, SQL, and more
| Name | Required | Description | Default |
|---|---|---|---|
| environments | No | Filter by environment type | |
| include_data_store_details | No | Include datastore details for VMware sources |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits, but it only states the action without discussing pagination, performance, authentication requirements, or what happens when no sources exist. The description fails to add value beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it could be slightly more informative without sacrificing conciseness, hence a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the optional parameters and lack of output schema, the description is incomplete. It does not explain that sources can be filtered by environment or that datastore details can be included, leaving the agent without critical usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description hints at the 'environments' parameter via examples but does not add new information about the parameters or their usage, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all registered Cohesity protection sources', and provides specific examples (vSphere, Physical servers, NAS, SQL) that differentiate it from sibling tools like 'get_source' which targets a single source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., 'get_source' for a specific source), nor does it mention the optional filtering capability or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a Cohesity alert as resolved
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes | Alert ID to resolve | |
| resolution_summary | No | Summary of how the alert was resolved | |
| resolution_details | No | Detailed description of the resolution actions taken |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose side effects. It only states the action ('mark as resolved') without mentioning permissions, whether the change is reversible, or any downstream effects like notifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 6 words is very concise. It conveys purpose without wasted words, but lacks any structure or additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and no usage guidelines. For a mutation tool, it lacks behavioral context like whether the action is undoable or if confirmation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all three parameters have descriptions). The description adds no extra information about parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource combination: 'Mark a Cohesity alert as resolved'. This clearly distinguishes from sibling tools like list_alerts (listing) and get_* (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, nor any prerequisites or exceptions. The description does not mention when not to use it or what conditions must be met (e.g., alert must be active).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger an on-demand backup run for a Cohesity protection group
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Protection group ID to run | |
| run_type | No | Type of backup run: kRegular (incremental), kFull, kLog (log backup), kSystem | kRegular |
| objects | No | Specific objects to back up. Omit to back up all objects in the group. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It only states the basic action (triggering a run) without disclosing whether the operation is synchronous, what the return value is, or any side effects (e.g., does it wait for completion?). This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded with the action, but it could be slightly longer to include essential context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and no output schema, the description fails to explain the result of the operation, expected behavior (e.g., async vs sync), or how to interpret the response. It is too minimal for an action-triggering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The tool description adds no extra meaning beyond the schema, repeating the overall purpose without detailing parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger an on-demand backup run') and the resource ('Cohesity protection group'), using a specific verb that distinguishes it from sibling tools like 'get_protection_group' or 'list_protection_groups'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for on-demand runs but provides no explicit guidance on when to use it versus scheduled backups or other alternatives. It lacks prerequisites, exclusions, or context for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_cluster_infoget_cluster_statsget_protection_groupget_protection_runget_recovery_taskget_sourcelist_alertslist_protection_groupslist_protection_policieslist_protection_runslist_recovery_taskslist_sourcesresolve_alertrun_protection_groupScored across 14 tools
Each tool targets a distinct entity and action (e.g., get_cluster_info vs get_cluster_stats, list_protection_groups vs list_protection_policies), with no overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case, such as get_cluster_info, list_alerts, run_protection_group, resolve_alert.
14 tools cover the typical operations for a data protection domain without being excessive or insufficient, balancing detail and scope.
The set lacks create/update/delete operations for protection groups and policies, which are common lifecycle actions; agents may need those for full management.
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Connect your AI assistants to Keboola and expose your data, transformations, SQL queries, ...
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
