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., "@WatchGuard Cloud MCP Server List all managed accounts in WatchGuard Cloud"
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.
MCP server for WatchGuard Cloud's REST API - MSP account management, device/license activation, and operator (user) management - for AI assistants and the WYRE Conduit gateway.
Enable API access in WatchGuard Cloud (Account Settings > API Access) to receive two independent credentials:
An AccessID/Password pair, exchanged for a short-lived (1-hour) OAuth access token via POST /oauth/token (grant_type=client_credentials, HTTP Basic auth). This server handles that exchange, and its refresh on expiry, internally.
A separate WatchGuard-API-Key, sent as its own header on every request alongside the OAuth bearer token.
Callers only ever need to supply the three long-lived values below - not the short-lived access token.
Related MCP server: Firewalla MSP MCP Server
Env var | Description |
| AccessID from WatchGuard Cloud API Access. |
| Password paired with the AccessID. |
| WatchGuard-API-Key generated when API access is enabled. |
|
|
|
|
|
|
| When set, the HTTP transport requires a valid |
|
|
watchguardcloud_get_account - get an account's details.
watchguardcloud_create_account - create a managed (child) account.
watchguardcloud_update_account - update a managed account's name/primary contact.
watchguardcloud_delete_account - delete a managed account.
watchguardcloud_list_managed_accounts - list accounts managed by (delegated from) an account.
watchguardcloud_create_activation - activate a Firebox/hardware device or SaaS license by activation key.
watchguardcloud_list_recent_activations - list activation batches from roughly the last 30 days.
watchguardcloud_get_activation_status - per-line-item status for an activation batch.
watchguardcloud_create_operator - create an operator (user) account with a privilege role.
watchguardcloud_update_operator - update an operator's name/phone/role.
watchguardcloud_delete_operator - delete an operator account.
watchguardcloud_get_operator_transaction_status - poll an async create/update/delete result.
watchguardcloud_list_operators - list every operator and its role/MFA status for an account.
This is a v1 surface covering the three best-documented WatchGuard Cloud platform APIs (account, activation, and operator management). Explicitly out of scope for now: Firebox device configuration/management and Endpoint Security policy management - both exist as separate WatchGuard APIs, but their public documentation does not (at the time of writing) carry enough concrete request/response detail to implement with confidence. They can be added as a follow-up once better-documented.
npm install
npm run build
npm test
npm run lint # tsc --noEmitdocker build -t watchguard-cloud-mcp .
docker run -p 8080:8080 \
-e WATCHGUARDCLOUD_ACCESS_ID=... \
-e WATCHGUARDCLOUD_PASSWORD=... \
-e WATCHGUARDCLOUD_API_KEY=... \
watchguard-cloud-mcpCreate a new managed (child) account under a parent WatchGuard Cloud account.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | 1 = Service Provider, 2 = Subscriber. | |
| Yes | Primary contact email. | ||
| lastName | Yes | Primary contact last name. | |
| firstName | Yes | Primary contact first name. | |
| parentAccountId | Yes | Parent WatchGuard Cloud account ID to create the account under. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the action and relationship, without covering expected side effects, permissions, idempotency, failure behavior, or what the response contains.
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 with no redundant wording. The key resource and relationship are front-loaded, making it easy to scan.
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 mutation tool with no annotations, no output schema, and six required parameters, this description is thin. It does not mention the response format, required permissions, how the account type maps to the 'type' parameter, or what happens after creation, leaving an agent without enough context to robustly handle results.
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 already documents 5 of 6 parameters, and the description adds little beyond the 'parent' context that is already present in parentAccountId. The high schema coverage justifies the baseline 3, though the description itself contributes minimal parameter-level meaning.
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 states a specific action ('Create') on a specific resource ('managed (child) account') and includes the parent-account relationship, which clearly distinguishes it from sibling operators like watchguardcloud_create_activation and watchguardcloud_create_operator.
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 when to use the tool—when creating a managed child account under a parent—but it does not explicitly mention alternatives or provide when-not-to-use guidance. No sibling tool is referenced, so an agent must infer the boundary from the names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate one or more Firebox/hardware devices or SaaS licenses by activation key.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'activate', which implies a state change, but does not disclose side effects, idempotency, partial-failure behavior, or whether the operation is asynchronous.
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 one short, front-loaded sentence with no filler. It communicates the core action, target resource, and input mechanism efficiently.
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 mutating operation with no annotations and no output schema, the description is thin. It gives no indication of synchronous versus asynchronous behavior, status reporting, or how partial activation failures are handled, so an agent lacks important operational context beyond 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?
The description adds some meaning to the schema by saying 'one or more' and linking activation keys to hardware devices or SaaS licenses, which maps to deviceDetails and saasDetails. However, it leaves optional fields like accountId and nested constraints unexplained.
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 states an explicit verb ('Activate'), a specific resource ('Firebox/hardware devices or SaaS licenses'), and the required input mechanism ('by activation key'). This clearly distinguishes the tool from status, listing, account, and operator siblings.
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?
There is no guidance on when to use this tool versus related tools such as watchguardcloud_get_activation_status or watchguardcloud_list_recent_activations. It also does not mention any prerequisites, exclusions, or post-activation verification steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a WatchGuard Cloud operator (user) account with an assigned privilege role. Role options depend on whether the account is a Service Provider (OWNER, SALES, HELPDESK, AUDITOR, NO_ACCESS) or a Subscriber (ADMINISTRATOR, ANALYST, OBSERVER, NO_ACCESS).
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | ||
| Yes | |||
| phone | Yes | 6-40 digits. | |
| lastName | Yes | ||
| password | No | Optional. Min 12 chars with upper/lower/number/symbol. | |
| username | Yes | 5-65 chars: letters, numbers, periods, hyphens, underscores, plus signs. | |
| accountId | Yes | ||
| firstName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that this is a mutating operation (creation) or any side effects, permission requirements, or constraints. The description only mentions role options, but omits details like password requirements (which are in the schema) and whether there are limits on account creation. This is a significant gap for a creation tool without annotations.
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 fluff. It front-loads the action (create) and resource (operator account), then provides essential role context. 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 the tool's complexity (8 parameters, 7 required, creation operation) with no annotations and no output schema, the description is somewhat under-informative. It explains role options but does not clarify the accountId's meaning, which is likely critical for distinguishing Service Provider vs Subscriber. Also, it does not mention any response or errors. However, the role detail is a meaningful addition, so it is not completely inadequate.
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 schema covers about 38% of parameters with descriptions (phone, password, username), but the description does not elaborate on parameters. It mentions role options and the distinction between account types, adding value by clarifying the role enum. However, it does not explain the meaning of accountId, firstName, lastName, or email beyond what the schema provides. Since schema coverage is low, the description could have compensated but did not do so fully.
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 creates a WatchGuard Cloud operator account with an assigned role, using a specific verb and resource. It distinguishes from sibling tools like 'update_operator' because the action is explicitly 'create'. However, it does not directly name siblings, but the purpose is clear enough.
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 explains the role options based on account type (Service Provider vs Subscriber), which gives context on when to use which role. However, it does not explicitly state when to use this tool versus alternatives (e.g., update_operator for existing accounts) or when not to use it. The context of creating a new operator is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a managed WatchGuard Cloud account. Set force to also delete its child accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Also delete child accounts. Default false. | |
| accountId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the destructive nature ('Delete') and the cascading effect of 'force' on child accounts. However, it does not mention irreversibility, required permissions, or what happens when child accounts exist and force is false.
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 two short sentences with no filler. The primary action is front-loaded, and the optional force behavior is stated immediately after, making it easy to parse quickly.
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 simple two-parameter destructive tool, the description covers the main action and the force option. However, with no annotations and no output schema, it leaves unclear consequences such as failure when child accounts exist without force, and it does not describe the response or side effects beyond deletion.
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 force parameter is already described in the schema, and the description mostly restates it. The accountId parameter has no schema description, and the description only indirectly implies it identifies the account to delete. It adds little meaning beyond what the parameter names and schema already convey.
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 names a specific verb ('Delete') and a specific resource ('managed WatchGuard Cloud account'), and the 'force' clause adds the scope of deletion. This clearly differentiates it from sibling tools such as watchguardcloud_get_account, watchguardcloud_create_account, and watchguardcloud_delete_operator.
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 when to use the tool: whenever a managed WatchGuard Cloud account needs to be deleted. However, it does not explicitly state when not to use it or name alternatives, such as watchguardcloud_delete_operator for deleting operators instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a WatchGuard Cloud operator (user) account.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | ||
| accountId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. 'Delete' indicates a destructive mutation, but it does not disclose whether deletion is permanent, reversible, what side effects occur, or whether special permissions are required. This is comparable to the under-disclosed update_drive case.
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 sentence with no filler; the key verb and object are front-loaded and every word contributes. This is concise without being padded, and the length is appropriate to the tool's simplicity.
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 destructive mutation with no annotations and no output schema, the description is too thin: it omits prerequisites, permission checks, side effects, and any indication of what the response will be. The agent can call the tool by name but not confidently assess implications or recover from misuse.
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 0%, and the description adds no parameter-level detail. The parameter names 'username' and 'accountId' are reasonably self-explanatory, but the text does not clarify which account the ID refers to, what the expected formats are, or how to obtain valid values.
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 states a specific verb ('Delete') and resource ('WatchGuard Cloud operator (user) account'), making the tool's function clear and separating it from sibling operators such as create_operator, update_operator, and delete_account. The parenthetical '(user)' removes ambiguity about what an operator is.
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 given on when to prefer this tool over alternatives, when not to use it, or any prerequisites such as permission requirements. It neither names sibling alternatives nor explains how deletion differs from deactivation or update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a WatchGuard Cloud account by ID, optionally expanded with contacts/addresses/service properties.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional extra fields to include in the response. | |
| accountId | Yes | WatchGuard Cloud account ID, e.g. ACC-1234567. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' conveys a read operation and optional expansion describes response scope, but it does not disclose error/not-found behavior, required permissions, or whether any fields are returned by default.
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 states the core action, the lookup key, and the optional expansion behavior with no filler or repetition.
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 low-complexity get-by-ID tool with 100% schema parameter coverage, the description covers what it does and what optional data can be included. It omits response/error details, but there is no output schema and nothing else requires more 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 description coverage is 100%, so the schema already documents both parameters. The description's mention of 'contacts/addresses/service properties' loosely mirrors the fields enum but adds no new parameter semantics; 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 names a specific verb ('Get'), resource ('WatchGuard Cloud account'), and selection key ('by ID'), and notes the optional expansion fields. This clearly distinguishes it from create/update/delete and list_managed_accounts siblings.
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 given about when to prefer this tool over list_managed_accounts or the other account/operator operations, and no exclusions or prerequisites are stated. The only implied context is that a caller needs an account ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get per-line-item status for an activation batch by batch ID.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| sortBy | No | ||
| batchId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. 'Get' makes the read-only nature clear, and 'per-line-item status' hints at the response granularity. However, it does not disclose pagination behavior implied by limit/offset, response structure, authentication requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, with no redundant or vague wording. It is appropriately sized for what appears to be a straightforward status lookup tool.
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?
There is no output schema and no annotation context, so the description should at least clarify return semantics and pagination. It mentions 'per-line-item status' but does not explain what line items are, how results are returned or paged, or how the optional sortBy parameter behaves, leaving an agent with insufficient detail for robust 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?
The input schema has 0% description coverage, so the description needed to compensate for all four parameters. It only adds meaning to batchId as the lookup key; limit, offset, and sortBy are left entirely unexplained, leaving most parameters semantically opaque.
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 identifies the operation as retrieving per-line-item status for an activation batch using a batch ID, which distinguishes it in resource and action from sibling creation/list tools. However, it does not explicitly contrast itself with similar sibling tools like get_operator_transaction_status, so it falls just 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_recent_activations or get_operator_transaction_status. It only implies that a batchId is needed, but offers no context about how to obtain it or when not to use this endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll the async result of a prior create/update/delete operator call by transaction ID.
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals that this is a polling operation for an asynchronous result, implying a read-only follow-up rather than a mutation. However, it does not disclose expected status values, error behavior, or whether the transaction ID expires.
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 with no wasted words. It front-loads the action ('Poll'), identifies the resource and the key parameter, and stays appropriately compact for such a simple tool.
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 one-parameter status-polling tool, the description is minimally adequate: it states what to poll and how to identify the transaction. However, with no output schema and no annotations, it omits expected return values, possible statuses, and error cases, leaving some ambiguity for an agent needing to interpret results.
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 schema provides only a string property named transactionId with 0% description coverage. The description adds the useful context that this ID comes from a prior create/update/delete operator call, but it does not explain the ID's format, how it is returned, or any validation details.
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 ('Poll') and names the exact resource ('async result of a prior create/update/delete operator call'), with the lookup key ('transaction ID') included. It is clear and distinct from sibling tools focused on accounts, activations, and operators themselves, though it does not explicitly contrast with those siblings.
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 phrase 'prior create/update/delete operator call' provides clear context for when this tool should be used: after an asynchronous operator mutation. It does not explicitly list exclusion cases or alternatives, but the intended usage is unambiguous enough for an agent to route to it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List accounts managed by (delegated from) a WatchGuard Cloud account, with paging/sorting/filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by account name. | |
| type | No | 0 = all, 1 = Service Provider, 2 = Subscriber. | |
| limit | No | Records per page; -1 returns all. | |
| offset | No | ||
| sortBy | No | ||
| accountId | Yes | ||
| sortOrder | No | ||
| includeDelegatedAccounts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It communicates that this is a read-only listing operation with paging/sorting/filtering, but it does not explain delegation semantics, recursion behavior, auth needs, or response shape. Some behavioral context is present, but important gaps remain.
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 front-loaded sentence with no filler. It states the resource, the relationship, and the available capabilities efficiently.
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 an 8-parameter list tool with no output schema and no annotations, this description is incomplete. It fails to explain key semantics such as the meaning of includeDelegatedAccounts, the required accountId, and the sort/filter parameter details, leaving an agent likely to invoke it incorrectly or misread results.
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 only 38%, so the description must compensate. It only refers generically to paging/sorting/filtering and does not clarify accountId, offset, sortBy, sortOrder, or includeDelegatedAccounts, all of which are effectively undocumented in both schema and description.
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 the specific verb 'List' and clearly identifies the resource as accounts managed by (delegated from) a WatchGuard Cloud account. It also adds paging/sorting/filtering, which distinguishes it from sibling tools like list_operators and list_recent_activations.
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?
There is no guidance on when to use this tool versus alternative list endpoints, nor any mention of prerequisites or exclusions. The intended use is only implied by the tool name and resource phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every operator (user) account and its role/MFA status for a WatchGuard Cloud account.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does disclose that the tool returns the list of operators with role/MFA status and is read-only by the verb 'List'. However, it does not mention pagination, required permissions, response format, or potential errors, leaving some gaps for a fully transparent read operation.
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 immediately states the action and object. It contains no filler, and every phrase ('every operator', 'role/MFA status', 'for a WatchGuard Cloud account') adds necessary scope or 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?
For a simple list operation with one parameter and no output schema, the description provides enough conceptual detail: it names the resource, the scope, and the specific fields returned. It does not describe pagination or navigation, and there are no annotations or output schema to fill those gaps, but the core invocation context is clear.
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 0%, so the description must compensate. It does add meaning by mapping the sole parameter to 'a WatchGuard Cloud account', clarifying that accountId identifies the target account. However, it does not explain the format of accountId, how to obtain it, or any constraints beyond being a string.
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 ('List') and a precise resource ('operator (user) account') and further specifies what is returned (role/MFA status). This clearly distinguishes it from siblings like list_managed_accounts (which lists accounts, not operators) and the create/update/delete operator 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 implies this tool should be used when you need to enumerate operators and their role/MFA status for a WatchGuard Cloud account. However, it does not explicitly state when to prefer it over alternatives or mention any exclusions, such as using list_managed_accounts for sub-accounts or get_operator_transaction_status for operation status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List activation batches submitted in roughly the last 30 days for the account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| sortBy | No | e.g. 'LastModified'. |
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 adds the 'roughly last 30 days' filtering trait, but does not mention whether the operation is read-only, how pagination behaves, what ordering is applied, or what a response contains.
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 one concise, front-loaded sentence with no filler. Every word contributes to defining the operation's scope.
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 simple list operation with optional parameters, the description is adequate but thin. It omits pagination/ordering behavior and does not clarify how limit/offset interact with the 30-day filter, leaving room for an agent to make incorrect assumptions.
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 only 33%, and the description does not compensate. It does not explain limit, offset, or sortBy beyond the schema's lone example for sortBy. The '30 days' time window is context, not parameter semantics.
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 ('List'), a specific resource ('activation batches'), and a scope ('roughly the last 30 days for the account'). It is clearly distinct from siblings like get_activation_status and create_activation.
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 says what the tool does but provides no guidance on when to use it versus alternatives, nor any exclusions. An agent must infer usage entirely from the tool name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a managed account's name and primary contact.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| Yes | |||
| lastName | Yes | ||
| accountId | Yes | ||
| firstName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Update' without explaining side effects, such as whether existing data is overwritten, whether the account must already exist, what authentication is required, or what happens on failure. For a mutation tool, this is a significant gap.
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 that starts with the action and resource. It contains no redundant words and is easy to parse quickly.
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 this is a mutation tool with five parameters, no output schema, and no annotations, the description is far from complete. It does not disclose what the tool returns (e.g., updated account object, success message), or how errors like nonexistent accounts are handled. An agent calling this would have no idea what to expect after executing it.
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?
With 0% schema description coverage, the description must explain the parameters. It covers most of them by mapping 'name' and 'primary contact' to the name, firstName, lastName, and email fields. However, it does not explain that accountId is the identifier for the account to update, nor does it provide any constraint details (e.g., email format, uniqueness). It adds some meaning but not complete compensation.
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 ('Update') and the resource (a managed account), and specifies the exact fields being changed ('name and primary contact'). This distinguishes it from sibling tools like create_account, delete_account, and get_account, which are obviously different operations.
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. It does not mention that create_account should be used for new accounts, get_account for retrieval, or that this is the only way to modify account details. The usage context is only implicit 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.
Update an existing WatchGuard Cloud operator's name, phone, or privilege role.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| phone | No | ||
| lastName | No | ||
| username | Yes | ||
| accountId | Yes | ||
| firstName | No |
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 conveys that the operation mutates an operator's fields, but it does not mention required privileges, async behavior (notable given the sibling get_operator_transaction_status), return/transaction semantics, or the effect on omitted 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 that front-loads the verb and resource, states the scope, and contains no filler or redundant information.
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 mutation tool with six parameters, no annotations, and no output schema, this description is too thin. It omits response/status behavior, async implications, permission requirements, and the identification role of the required parameters, leaving an agent with too much to infer.
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 0%, so the description must compensate. It adds some meaning by mapping 'phone' and 'privilege role' to parameters, but it does not explain that username and accountId identify the target operator, nor does it disambiguate 'name' into firstName and lastName.
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 ('Update'), a specific resource ('an existing WatchGuard Cloud operator'), and lists the changeable fields ('name, phone, or privilege role'). This clearly distinguishes it from sibling tools such as create_operator and delete_operator.
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 word 'existing' implies the operator must already exist, which weakly distinguishes this from create_operator. However, the description does not explicitly state when to use this tool over alternatives, nor does it mention any prerequisites or exclusions.
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.
v0.1.0watchguardcloud_create_accountwatchguardcloud_create_activationwatchguardcloud_create_operatorwatchguardcloud_delete_accountwatchguardcloud_delete_operatorwatchguardcloud_get_accountwatchguardcloud_get_activation_statuswatchguardcloud_get_operator_transaction_statuswatchguardcloud_list_managed_accountswatchguardcloud_list_operatorswatchguardcloud_list_recent_activationswatchguardcloud_update_accountwatchguardcloud_update_operatorScored across 13 tools
Each tool targets a clear resource-action combination: accounts, activations, or operators. Even the two status tools are distinguishable by batch/transaction context. There is no meaningful overlap between tool purposes.
All tools follow the consistent watchguardcloud_ verb_noun pattern. Verbs are get, create, update, delete, list, which map predictably to the resource nouns. This makes the toolset easy to navigate.
13 tools is well-scoped for a cloud management server covering accounts, activations, and operators. Each tool handles a distinct operation, and none feel redundant or unnecessary. The count supports the domain without becoming unwieldy.
The toolset covers the main lifecycle operations for accounts, activations, and operators: create, read, update, delete, and list where applicable. Async operator operations are supported via transaction status polling, closing an important workflow gap. The domain appears thoroughly covered for its stated purpose.
Connect any AI assistant to Syncro: manage tickets, invoices, customers, assets, and more.
Give your AI agents trusted access to the full Postman platform.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
Credential broker for AI agents: scoped, revocable API access with policy enforcement and audit.
