Dokploy MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers real value: it discloses merge-not-replace semantics, a mandatory two-phase dry-run/revision workflow, a hard refusal case ('Complex multiline documents are refused'), and a concurrency limitation. It omits auth/permission requirements and whether changes are reversible.

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?

Three dense sentences with the operation stated first, the workflow second, and the two constraints last. No filler, every clause carries actionable 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?

There is no output schema, and the description covers the key return dependency ('returned revision'), so an agent can complete the typical workflow. Minor incompleteness: no statement of what the response contains beyond revision or what error states look like.

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 explains the semantics of dry_run and revision well (dry-run gating and revision round-trip), but says nothing about application_id, nor about the set/remove shape and whether removal is key-name based. Partial compensation for an undocumented 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?

States a specific verb and resource ('Patch runtime variables') plus the merge scope ('preserving other keys and build settings'), so the agent knows exactly what is modified and what is left intact. No sibling tool overlaps this operation, so no sibling differentiation is required.

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?

Gives a concrete operating procedure ('First dry_run=true, then supply returned revision with dry_run=false') and a when-not caveat ('Not an atomic concurrency lock'). It does not name an alternative tool to use for atomic/concurrent updates, which is the only gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It usefully discloses a safety gate ('confirm must equal record_id'), giving real context beyond the schema's bare string type, but omits permission requirements, reversibility, and error/failure behavior expected of a destructive 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?

Two compact sentences, front-loaded with the action and immediately followed by the one constraint that matters. No filler.

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 tool with no annotations and no output schema, the confirmation protocol is the key missing piece the description supplies. Still, permission/auth requirements and what a successful deletion returns are absent, so an agent lacks a full operational picture.

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 for all three parameters. It explains the semantics of 'confirm' (must equal record_id) but says nothing about zone_id or record_id beyond their self-evident names, so coverage is partial.

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?

States a specific verb ('Delete') and resource ('A/AAAA/CNAME record'), which distinguishes it from cloudflare_upsert and cloudflare_records at a glance. It does not explicitly name a sibling, but the destructive scope is unambiguous.

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?

'Explicitly authorized' implies a precondition for use, hinting the agent must confirm the record is sanctioned before deleting. However, it never states when to prefer this over cloudflare_upsert or how authorization is established, leaving usage largely inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation and notes pagination/filter support, but says nothing about return shape, permissions, rate limits, or what happens at page boundaries.

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 compact sentence with the action front-loaded and the capability details trailing. Nothing is wasted, though the brevity borders on under-specification for a 3-parameter 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?

With no annotations, no output schema, and 0% schema description coverage, the description would need to do more. It omits the required zone_id, pagination limits, and any indication of what record fields are returned.

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 clarifies that 'name' is an exact-match filter and that 'page' controls pagination, but the required zone_id parameter is never explained, leaving a third of the schema undocumented.

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?

Clear verb+resource: 'Inspect DNS records' with an added timing hint ('before changes'). It is distinguishable from cloudflare_upsert and cloudflare_delete by the read-oriented verb, though it never names a sibling to sharpen the boundary.

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?

'before changes' implies the use case (pre-flight verification before mutating records), but there is no explicit when-not guidance and no named alternative among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose useful behavior: dry_run defaults on (so calls are non-mutating by default), DNS-only/proxied-off by default, and the replace_id requirement for conflicting records. It omits auth/permission needs, idempotency, and what a dry-run 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?

Four tight sentences, front-loaded with purpose and immediately followed by defaults and the key edge case. No filler; every sentence carries signal, though the trailing SSL note could be folded into the boundary statement.

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 0% parameter coverage, the description should do more: return shape, permission requirements, and the undocumented ttl/name/content semantics are all missing. It covers the critical safety defaults but not the full operational picture.

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% across 8 parameters, so the description must compensate. It explains the meaning of dry_run, proxied, replace_id, and type, but leaves ttl, name, content, and zone_id undefined — roughly half the parameters remain 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?

States a specific verb pair (create/update) and the exact resource (A/AAAA/CNAME records), which an agent can distinguish from cloudflare_delete and cloudflare_records. However, it never names which sibling to prefer when a record may or may not already exist.

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?

Gives two concrete usage conditions: dry-run is the default, and replacing a differing existing record requires replace_id. It stops short of explicit when-to-use vs cloudflare_records/cloudflare_delete routing or when proxied should be turned on.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It discloses only the 'permitted' scope, implying an access restriction, but says nothing about rate limits, pagination termination, ordering, or what a page contains — all relevant for a paginated listing tool.

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 tight sentence with the verb, resource, and scope front-loaded and no filler. The semicolon clause about pagination is useful, though the phrasing is slightly clipped.

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 optional-parameter listing tool with no output schema, the description covers the core purpose but leaves the agent guessing about default paging behavior and whether pagination metadata is returned. It is the minimum viable level of completeness rather than fully adequate.

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 one parameter and 0% schema description coverage, the description must compensate; it does identify that 'page' is the pagination control, which the schema (integer, min 1) does not state. However, it omits the default page and page size semantics, so the compensation is only partial.

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?

States a specific verb and resource ('List permitted Cloudflare zones') plus the access scope ('permitted'), which is enough to distinguish it from mutation siblings like cloudflare_upsert and cloudflare_delete. It stops short of naming how it differs from cloudflare_records, so it is clear but not sibling-differentiated.

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 explicit when-to-use or when-not-to-use guidance. The description never mentions the alternative cloudflare_records (for DNS records within zones) or any prerequisite for listing zones, leaving the agent to infer selection from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does disclose two meaningful traits: it is local-only and does not contact APIs (so no side effects, no network latency, no auth requirements), and its output does not expose credentials. It does not describe the shape or content of the returned status.

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?

Two short sentences, front-loaded with what the tool returns and followed by the key behavioral constraint. No filler, though the extreme brevity borders on under-specification for a tool with no output schema.

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-param, no-annotation, no-output-schema tool the description is adequate on safety and scope, but it never says what the status actually contains (e.g. whether it reports connectivity, credential presence, or config validity). Without an output schema, some indication of the return content would be expected.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The 'additionalProperties: false' empty schema is self-explanatory and needs no prose support.

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?

States a specific resource and scope: local configuration status, with the qualifier that it reads local config rather than contacting services. An agent can tell it apart from the API-calling siblings (cloudflare_call, dokploy_call) by the explicit 'local' framing. It is slightly less clear about which connection/component the status pertains to, which keeps it from 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 line 'Does not contact APIs' implicitly routes the agent here when it wants status without network calls, but there is no explicit when-to-use statement and no sibling named as an alternative. Usage must be inferred from the exclusion rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It usefully discloses the resolver being local and the diagnostic limitation, but says nothing about timeout/error behavior on NXDOMAIN, which record types are queried, or whether results reflect caching.

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?

Two tight sentences, front-loaded with the core action and followed by a scoping caveat. 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 one-parameter read tool the description covers purpose and one limitation, but with no annotations and no output schema it leaves unaddressed what a successful or failed lookup returns and how errors surface. Adequate, 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?

Single required 'name' parameter with 0% schema description coverage, so the description must compensate. 'Resolve A/AAAA/CNAME' implies 'name' is a domain name, but the description never states the expected format (hostname, FQDN, trailing dot) or whether it can be a URL.

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?

States a specific verb (Resolve) with concrete record types (A/AAAA/CNAME) and scopes it to the local system resolver. The 'local system resolver' phrasing implicitly differentiates it from the cloudflare_records/cloudflare_zones siblings without naming them.

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 second sentence ('Does not prove global propagation or HTTPS health') sets scope boundaries, which is useful, but it never states when to prefer this tool over cloudflare_records or another DNS sibling. Usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does so well: it discloses mutation-preview behavior, the authorization/confirmation gate for destructive actions, and that results redact secret fields while logs may still leak application-generated text. What is missing is auth/permission requirements and rate-limit or pagination behavior for an umbrella dispatcher.

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?

Four dense sentences, front-loaded with the core action, each carrying distinct information (scope, preview, confirmation gate, redaction caveat). The domain enumeration is mildly list-heavy but earns its place by signaling coverage.

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 generic multi-domain dispatcher with no annotations, no output schema, and a nested opaque parameters object, the description covers safety and result handling but not how to construct valid parameters or discover endpoints. Adequate for a cautious agent, but incomplete 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 0%, so the description must compensate. It explains dry_run's preview semantics and gives the non-obvious rule that confirm must equal the endpoint value, but the central `parameters` object stays completely opaque and `endpoint` is only alluded to as 'catalogued' with no naming or format guidance.

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?

States a specific verb and resource ('Call a catalogued Dokploy endpoint with validated parameters') and enumerates the resource domains it covers, which lets an agent place it against dokploy_catalog. It never explicitly contrasts itself with the catalog/discovery sibling, so it is clear but not fully differentiated.

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?

Gives concrete usage conditions: dry_run previews mutations, and destructive actions require explicit user authorization plus confirm equal to the endpoint. It stops short of stating that dokploy_catalog should be consulted first to obtain a valid endpoint name, so one routing decision is left implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden, and it does add one real behavioral caveat: the snapshot may not match the installed version. However, it says nothing about pagination behavior despite limit/offset, no return shape, and no rate or caching characteristics, which is thin for a discovery tool with zero annotation coverage.

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?

Three short sentences, front-loaded with purpose and then the sequencing instruction; nothing is padded. It is slightly clipped to the point of being terse — the compatibility sentence is cryptic without context — but there is no waste.

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 annotations, no output schema, and 0% parameter coverage, the description leaves the agent without return format, pagination, or per-parameter meaning. The version-compatibility warning is genuinely useful but does not compensate for the rest of the missing 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 0% across four parameters (limit, offset, search, endpoint), and the description explains none of them. It never clarifies that 'endpoint' filters to one entry or that limit/offset paginate results, so it adds nothing beyond the bare schema names.

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?

States a specific verb and resource: 'Discover supported Dokploy endpoints and exact JSON parameter schemas.' It also names the sibling it precedes (dokploy_call), so an agent can place it in the workflow. It stops short of 5 because it doesn't make clear whether it returns a full catalog or a single endpoint lookup, which the 'endpoint' parameter implies.

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?

'Use before dokploy_call' gives explicit, actionable sequencing guidance that no sibling tool states. There is no when-not guidance and no statement of what happens if you skip it or call dokploy_call directly, which keeps it below a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.