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

With no annotations, the description carries the full burden and does so well: it discloses that get masks env values, that saveEnvironment is a full replace, that setEnvVars is a server-side read-modify-write returning only changed key names, and that getEnvValuesUnsafe exposes plaintext values into the transcript and retained logs. It also surfaces the first-deploy failure/retry quirk and the narrow search index.

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 'action: params' pattern is consistent and front-loaded after a one-line purpose statement, and given 24 actions and 45 parameters nearly every clause carries information. It is still a single dense paragraph with no visual breaks, which makes scanning for a specific action slower than it needs to be.

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 of this complexity with no output schema and sub-50% schema coverage, the description gives an agent enough to invoke each action correctly, including which actions read versus mutate env state and what each returns in summary form. Only peripheral build/resource-limit parameters are left unaddressed, which is acceptable given they belong to the already-enumerated update path.

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 49% across 45 parameters, so the description must compensate, and it does for the action-critical ones — mapping action to required fields and clarifying semantics like 'KEY=VALUE pairs, full replace' versus upsert plus unset. However, a sizeable set of update parameters (command, cpuLimit, memoryLimit, replicas, buildArgs, dockerfile, publishDirectory, autoDeploy, createEnvFile) is named in a bare list without explanation or the schema documenting them.

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 the resource ('applications') and then enumerates every action with its required parameters, so an agent knows exactly which operation each action value performs. It also names related sibling tools (dokploy_project, dokploy_overview, dokploy_network) in contrasting contexts, distinguishing this tool from adjacent ones.

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?

Several actions carry explicit when-to-use guidance: getEnvValuesUnsafe is flagged 'use only when you need actual values', search is scoped to finding a known service rather than inventorying, and the deploy note warns of a retry pattern. It doesn't systematically contrast application actions against dokploy_compose or dokploy_database alternatives, so it stops short of full routing guidance.

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 burden and does well by indicating this is a read operation, listing all filters, and explicitly documenting the wire-level vs MCP parameter naming. It does not describe the return format or pagination behavior beyond limit/offset, but the provided details are substantial.

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 three sentences, front-loaded with the core purpose, and every sentence provides essential information. It is dense but well-structured, making efficient use of space.

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 10 parameters, no output schema, and no annotations, the description covers all parameters, provides defaults and limits, and clarifies a potential naming conflict. It does not describe the output structure, but that is not essential for invocation. Overall, it is sufficiently complete for an agent to select and use the tool correctly.

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 30%, so the description compensates by explaining all filter parameters, enumerating allowed values for auditAction and resourceType, and adding default/max information for limit and offset. This adds significant semantic 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 starts with 'Read the Dokploy audit log with filters', which clearly specifies the verb (Read), resource (audit log), and scope (with filters). It distinguishes itself from sibling tools that focus on specific resources like projects or deployments.

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 clearly implies when to use the tool (reading audit logs) and states that the only action is 'list', which defines the operation scope. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficiently clear given 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 available, the description carries the full burden of behavioral disclosure. It fails to state side effects (e.g., 'remove' is destructive), permission requirements, failure modes, or return values. The only behavioral hint is that includeEncryptionKey stores the encryption key, which is more parameter semantics.

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 dense but efficient, using compact colon-separated summaries for each action. Every sentence provides actionable information, though the lack of formatting makes it somewhat hard to scan. It is appropriately sized for the tool's complexity.

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?

The tool is complex with 20 parameters and no output schema or annotations. The description covers the main actions and key parameter relationships, but misses several parameters, return value details, and operational caveats. It is adequate for basic selection and invocation 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?

Schema description coverage is only 20%, but the description compensates by explaining action-specific parameter combinations and enum relationships (e.g., databaseType to postgresId/mysqlId/mariadbId, manualBackup backupType variants). However, it leaves some parameters unexplained (search, enabled, keepLatestCount, serverId) and the 'update: backupId+fields' is vague.

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 begins with 'Manage backups' and then enumerates the specific actions (create, get, update, remove, listFiles, manualBackup), making the tool's purpose clear. It does not explicitly differentiate itself from the sibling dokploy_volume_backup, but the action list and parameter requirements are specific 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 maps each action to its required parameters (e.g., 'get: backupId', 'remove: backupId', 'listFiles: destinationId') and gives conditional guidance for compose-stack backups. It does not explicitly mention when to prefer this over dokploy_volume_backup or other siblings, but it provides practical usage context.

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 so well: it discloses that deploy is DESTRUCTIVE (runs `docker compose down --volumes`, deletes volume data), that get returns a masked env summary, that getEnvValuesUnsafe is an unsafe escape hatch writing full secrets to the transcript, that saveEnvironment is a full replace, and that first deploy may fail and should be retried.

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?

Dense but front-loaded: the general verb+resource leads, then action-by-action parameter requirements follow in a scannable run-on structure. Nearly every clause conveys actionable information, though the single-block paragraph format makes it harder to parse than a bulleted layout would.

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 40-parameter, no-annotation, no-output-schema tool, the description covers destructive behavior, secret handling, action prerequisites, and return-value caveats (masked env, KEY-only vs KEY=VALUE). Coverage is strong; residual gaps are the handful of parameters undocumented anywhere.

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 65% across 40 parameters, but the description compensates by mapping actions to their required fields and explaining semantics not in the schema (sourceType gitlab/bitbucket caveat, serviceNetworks requiring all three fields, redeploy/freshVolumes behavior). Some parameters (deleteVolumes, deployDescription, composeType) remain unexplained in both places.

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?

Opens with a specific verb+resource ('Manage Docker Compose services') and then enumerates every supported action with its distinguishing inputs. This lets an agent distinguish it from siblings like dokploy_application and dokploy_deployment without opening the schema.

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?

Provides per-action routing guidance and sequencing prerequisites (e.g. 'loadServices: must deploy first', search 'use it to find a known service, not to inventory'). It lacks an explicit comparison against sibling tools such as dokploy_application (when to pick compose vs application), so it falls short of a 5.

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 burden and carries it well. It discloses masking ('returns metadata + masked env summary — never values'), an unsafe path ('UNSAFE escape hatch that returns full KEY=VALUE pairs'), destructive semantics ('saveEnvironment ... (full replace)'), merge behavior ('merge inside the server, masked confirmation only'), search-index limitations, and per-engine constraints ('mongo: REUIREs databaseUser (databaseName not used)'; 'redis: only databasePassword'). This is exactly the behavioral context annotations would only hint at.

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?

Every clause carries required-parameter information; there is zero filler. However, it is one dense unbroken paragraph covering 17 actions and 6 engines, which makes scanning harder than if it were broken into per-action lines. For a dispatch tool of this breadth the length is justified, but the structure could be cleaner.

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 17 actions, 6 dbTypes, 31 params, no annotations, and no output schema, the description covers per-action contracts, per-engine constraints, return-value masking, and search caveats — an unusually high bar. Remaining gaps: 'update: dbType+databaseId+fields' never enumerates which fields are updatable, and schema params command/cpULimit/memoriLimit/serverId apear nowhere in the description, leaving an agent unsure how to set resource limits or associate a server.

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 45% and many params (name, databaseId, databasePassword, environmentId, externalPort, etc.) have no schema description. The description fully compensates by mapping every param to its action and engine: create=dbType+name+environmentId+databasePassword, with per-engine REQUIRES/accepts/not-used rules; get/update/move/start/stop/deploy/rebuild/emove/reload/changeStatus/saveEnvironment/setEnvVars/getEnvKeys/getEnvValuesUnsafe/saveExternalPort/search each get their param sets. This removes real ambiguity that the bare schema would leave.

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 opening line 'Manage databases (postgres/mysql/mariadb/mongo/redis/libsql)' states a specific resource and scope, and the 17 enumerated actions each get a verb+parameter contract. The database scope clearly distinguishes it from siblings like dokploy_application, dokploy_compose, and dokploy_docker without needing to open their schemas.

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 search note is an explicit usage guideline: it warns the index is narrower than the project tree, can return fewer results than dokploy_project/dokploy_overview, and says to use search to find a known service, not to inventory. For the other 16 actions, when-to-use is implied by the action names and per-action parameter requirements, but no explicit exclusions are given for when to prefer a sibling (e.g., backup vs. database tool).

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 exist, so the description must disclose effects. It states that killProcess 'kill[s] an in-flight build' and remove 'drops the record', which surfaces destructive behavior. It doesn't address permissions, reversibility, return formats, or side effects, leaving gaps for a management 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?

The description is a compact single paragraph using action:usage pairs, front-loading the purpose and wasting no words. Each clause adds information, and the final exclusion is succinct.

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 5-action tool with 8 parameters and no annotations, the description covers action selection, parameter combination, and a notable exclusion. It doesn't describe return values or failure modes, so it's not fully complete but adequate for basic 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 only 38%, but the description compensates by mapping each action to its relevant parameters (e.g., list takes applicationId|composeId|serverId|type+id, readLogs takes deploymentId and optional tail). This gives meaning beyond the bare schema, though some param types like serverId and composeId lack deeper 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 enumerates five concrete actions (list, queueList, killProcess, readLogs, remove) under 'Manage deployments', giving a clear verb+resource pairing. It differentiates scope by noting database deployments are listed elsewhere, though it doesn't explicitly position sibling tools like dokploy_preview_deployment.

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?

Per-action parameter guidance tells the agent which parameters to supply for each operation, and the final sentence draws an exclusion boundary for database deployments. However, it never names an alternative tool or explains when to prefer this tool over related siblings, so it's only partial guidance.

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?

The description discloses that the 'test' action creates without persisting, which is a valuable behavioral trait. It also implies the CRUD nature of other actions. However, it does not discuss side effects (e.g., does removing a destination affect existing backups?), authorization needs, or rate limits. Given no annotations, the burden is higher, and the description provides only moderate transparency.

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 extremely concise, using compact notation to convey action-specific parameters. Every part adds value without redundancy. It is well-structured for quick parsing.

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 complexity of 11 parameters, no output schema, and no annotations, the description covers most necessary context for understanding how to use each action. It explains the test action's dry-run behavior and lists required fields. The missing serverId parameter and lack of return value explanation are minor gaps, but overall it provides sufficient guidance for an AI agent.

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 schema coverage at 27%, the description compensates by explaining which parameters are needed for each action and their roles (e.g., 'name+accessKey+bucket+region+endpoint+secretAccessKey' for create, 'provider?' as optional rclone hint, 'additionalFlags?' as rclone flags). However, 'serverId' appears in the schema but is not mentioned in the description, leaving a gap.

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 it manages S3-compatible backup destinations and enumerates specific actions (list, get, create, update, remove, test). This distinguishes it from sibling tools like dokploy_backup, which likely handles backup operations rather than destination configuration. However, it could be more explicit about its unique role.

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 per-action parameter requirements (e.g., list takes no params, create requires multiple fields). It implies when to use each action but offers no guidance on when to use this tool versus alternatives like dokploy_backup or dokploy_server. There is no mention of prerequisites or when not to use.

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 and does so well. It discloses that update REPLACES the provider (both name and config must be sent), that proxied only affects Cloudflare, that credentials are never echoed back, and exactly what provider reads return.

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 dense but front-loaded and well organized, with separate provider and record action groups. Every sentence adds operational detail, and there is no redundant restatement of the tool name or title.

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 11-parameter multi-action tool with no output schema and no annotations, the definition is highly complete on inputs and provider read behavior. It could be slightly richer on what zone and record list operations return, but the missing detail is minor.

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 substantial meaning beyond the 55% schema coverage: it maps every action to its required parameters, explains the discriminated config shapes per providerType, lists valid record types, clarifies recordName versus provider name, and notes the update caveat that both name and config are mandatory.

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 resource and scope: DNS provider configuration and DNS record management, then enumerates every action. It distinguishes the tool from neighboring resources like domains by content, but does not explicitly name or contrast with any sibling tool.

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?

Action-specific guidance is strong: each action is paired with its required identifiers, update semantics are called out, and testConnection is explained for both saved and unsaved credentials. The description does not provide when-not-to-use guidance or point to alternatives among 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 provided, the description carries the full behavioral disclosure burden, and it does so well. It warns that writeContainerFile writes into the running container and 'the change is lost on redeploy unless the path is a mount', discloses that readContainerFile output is 'truncated at 100k chars', and equates pruneBuildCache with a specific existing dokploy_settings action. These are exactly the kind of behavioral traits an agent cannot infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every clause adds operational value, and it is organized into clear sections: containers, container files, observability, and disk. The overview is front-loaded, and even parenthetical details like default ranges and truncation limits are compact. For a tool with 17 actions, this length is warranted and there is 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 complex 17-action tool with no output schema and no annotations, the description is remarkably complete: parameter bindings, defaults, min/max bounds, side effects, and equivalents are all present. The main missing piece is detailed return-shape information for actions like getContainers, getConfig, and getEvents, and explicit routing against sibling tools; these are not strictly required for selection and invocation but would make it fully self-contained.

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 55%, but the description substantially fills the gap by mapping parameters to actions: containerId+serverId for container operations, containerId+path for file operations, content for writeContainerFile, minutes with default 15, and sinceHours with max 168. It also explains the meaning of method values and the conditional requirement of type, which the schema alone does not connect to specific actions.

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 opens with 'Docker daemon management' and then enumerates exact action families: containers, files inside them, events, health, and disk usage. It names each operation with its parameters, so an agent knows precisely what resource and verb this tool exposes. The scope is distinct from sibling tools like dokploy_docker_volume and dokploy_docker_image, which target narrower resource types.

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 gives clear within-tool usage guidance, such as 'label → REQUIRES type: standalone|swarm' and 'match → fuzzy name match (optional appType...)', which helps an agent pick the right action and parameter combination. It does not explicitly say when to prefer this tool over a sibling, but the daemon-level scope and action categories make the intended context clear.

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 behavioral burden. It discloses that removeImage requires all three identifiers and that force is optional, and it explains a workflow (read values from getImages). However, it does not state consequences of removing an image, permission requirements, or what getImageConfig returns, leaving some behavior implied by the action names.

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 sentences pack the action inventory, parameter requirements, an example, and a sibling-tool pointer with zero filler. The most important scoping statement ('Docker image inventory') is 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 multi-action tool with no output schema and no annotations, the description covers each action's parameters and routing to the sibling tool. It is missing only minor behavioral details such as return shape for getImageConfig and removal side effects, but an agent has enough to call the tool correctly.

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 71%, so the schema already documents most parameters. The description adds value by showing a concrete imageRef example ('nginx:latest'), specifying that removeImage needs all three of repository/tag/id, and noting that they should be read off getImages — a dependency not visible in 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 opens with 'Docker image inventory' and enumerates three specific actions (getImages, getImageConfig, removeImage), each with a clear verb and target resource. It distinguishes this tool from dokploy_docker by pointing disk-usage and build-cache operations there.

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?

It gives explicit per-action usage: getImages for listing, getImageConfig with imageRef, and removeImage with the mandatory triplet repository/tag/id read from getImages, plus optional force/serverId. It also names dokploy_docker getDiskUsage/getBuildCache/pruneBuildCache as the alternative for disk usage and build cache, so an agent knows when not to use this tool.

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 burden of behavioral disclosure. It clearly warns that removeVolume destroys the volume and its data, documents that readVolumeFile is truncated at 100k chars, and explains that volume writes persist across redeploys.

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 dense but efficiently structured, front-loading the tool's purpose and then grouping actions clearly. Every clause adds information: optional serverId, raw inspect behavior, truncation, destructiveness, and sibling tool routing. There is little wasted wording.

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 multi-action tool with no output schema, the description covers the main behaviors, parameter requirements, safety warnings, and cross-tool distinctions. Missing return-format details for list/read actions are a minor gap, but an agent can still select and invoke the tool correctly.

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 40%, but the description compensates by mapping actions to their required parameters, e.g. getVolumeConfig: volumeName and file actions require volumeName + path, with writeVolumeFile also requiring content. It adds meaningful context beyond the bare schema, though it could be more explicit about path formatting.

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 opens with a specific verb and resource pair — 'Docker volume management and volume file access' — and then enumerates each action with its precise effect. It clearly distinguishes the tool from related siblings like dokploy_docker and dokploy_volume_backup.

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 gives explicit guidance on when to use volume file writes versus container writes, noting that volume writes survive redeploys. It also directs users to dokploy_volume_backup for scheduled backups and warns to take a backup before removeVolume.

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 it does disclose real behavior: toggleEnable is a blind flag flip, validate performs DNS-against-server-IP checking, and serverId omission targets the Dokploy host. However, it omits whether delete is permanent, what side effects create has (Traefik/cert provisioning), auth requirements, and certificate issuance implications, leaving significant behavioral 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?

Highly dense, front-loaded with the resource, then a tight action:params mapping. Every clause carries information and nothing is padded. The semicolon-heavy wall of text is compact but readable as a lookup table.

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 9-action, 15-param tool with no annotations and no output schema, the description covers action/parameter routing but omits return-value expectations, the semantics of five undocumented params, and the side effects of mutation actions. It is adequate but leaves an agent guessing on several invocation details.

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 20% across 15 params, so the description must compensate, and it does well on the identifier wiring (host+applicationId|composeId, domainId, appName, serverId, serviceName, enabled). But path, port, https, domainType, and certificateType are never mentioned in the description and lack schema docs, leaving a meaningful compensation gap.

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 opening 'Manage domains' is a generic umbrella, but the per-action breakdown (create/list/get/update/delete/toggleEnable/generate/canGenerateTraefikMe/validate) with their required identifiers makes the tool's scope and each operation concrete. An agent can tell this is the domain resource manager and distinguish it from siblings like dokploy_redirects or dokploy_dns_provider. It stops short of a crisp verb+resource statement and never says what a 'domain' record actually represents.

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?

Strong intra-tool routing: it explicitly says toggleEnable 'flips the enable flag blind' and to 'prefer update with enabled:true|false when you need a known end state', and clarifies validate's serverId is optional ('omit for the Dokploy host'). It does not give when-to-use-this-tool-vs-sibling guidance (e.g. domain vs redirect), but the action-selection advice is explicit.

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 must carry the full burden. It only lists parameters per action but fails to disclose side effects (e.g., whether remove is destructive, whether updates are partial, return values) or any safety/authorization concerns.

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 concise, listing all actions and their parameters in a compact format. It is front-loaded with the general purpose. Minor improvement could be clearer formatting (e.g., bullets), but no unnecessary text.

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 (5 parameters, no output schema, no annotations), the description is incomplete. It lacks details on update fields, the role of the description parameter, return values, error handling, and any behavioral constraints.

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 maps each action to required parameters (e.g., create needs projectId+name), which adds meaning beyond the schema's property names alone. However, it does not specify constraints on parameters like name or what 'fields' includes for update, limiting completeness.

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 'Manage project environments' and lists all supported actions (create, get, list, update, remove, duplicate) with required parameters. This distinguishes it from sibling tools like dokploy_project, which handles project-level 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 implies usage for environment management through its name and listed actions, but does not explicitly state when to use this tool over alternatives, nor does it provide context about prerequisites or exclusions.

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?

Without annotations, the description fails to disclose behavioral traits like side effects, permissions, or reversibility. It only lists actions and parameters, providing minimal insight into the tool's behavior beyond the obvious mutation implied by action names.

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 concise, using a single sentence to state purpose and then a compact list of actions with parameters. It front-loads the general purpose, making it efficient, though the dense format might be slightly harder to parse.

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 multi-action tool with 16 parameters and no output schema, the description is adequate but incomplete. It covers input requirements per action but omits output specifics, error handling, prerequisites, or contextual usage scenarios.

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 low (13%), but the description compensates by explicitly mapping each action to its required parameters (e.g., createPort needs applicationId, publishedPort, targetPort). This adds significant meaning beyond the raw schema, though some 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?

The description clearly states the tool manages ports, auth, and certs, and lists specific actions with their required parameters. This distinguishes it from sibling tools which handle other aspects like applications, backups, or domains.

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 alternatives. The description does not mention contexts, prerequisites, or when not to use it, leaving the agent to infer based on action names 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?

No annotations are provided, so the description carries the full burden. It discloses the redeploy requirement but does not mention authorization, rate limits, side effects of removal, or return values. This is adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded with the main purpose, but the action listing is cluttered. It could benefit from bullet points or clearer formatting.

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 18 parameters, low schema coverage, and no annotations or output schema, the description covers action patterns but lacks details on return values, error scenarios, idempotency, and data loss implications.

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 low (39%). The description adds significant meaning by mapping actions to required parameters (e.g., type=volume needs volumeName). However, some parameters like mongoId, mysqlId 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?

The description clearly states 'Manage mounts (volumes, bind mounts, files) attached to services' and enumerates all sub-actions with required parameters, distinguishing it from sibling tools like dokploy_application or dokploy_deployment.

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?

It provides explicit context: 'Mount changes require a redeploy of the parent service to take effect.' It also gives patterns for each action (create, update, remove, etc.). However, it does not mention when not to use this tool or compare with alternatives.

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 well: it warns that recreate 'drops and re-adds the network so attached services are briefly disconnected', that resync 're-reads... without touching the network itself', and that inspect returns the raw Docker payload. It omits what remove destroys and whether operations are reversible or require elevated auth.

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?

Tight and front-loaded: it opens with the domain, then walks action-by-action with a consistent 'action: params' pattern. It is somewhat run-on and packs every branch into one paragraph, but nearly every clause 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?

For a 12-param, 9-action tool with nested ipam and no output schema, the description covers the critical decision points and destructive side effects. It doesn't explain the return shape for list/get (which the agent may need) or the impact of remove, leaving modest gaps.

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% across 12 params, but the description compensates by mapping each parameter to its action (serverId for list/networksToSync, networkId for get/inspect/remove/recreate/resync, name+driver+internal+attachable+enableIPv4/IPv6+mtu+ipam for create). This adds real meaning beyond the bare enum/type schema, though constraints like driver/overlay semantics are left to 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?

States 'Docker network management' then enumerates the nine actions with a specific verb+object for each (list, inspect, recreate, resync, import, etc.). It also names the sibling tools (dokploy_application/dokploy_compose) used for the adjacent task of attaching networks, distinguishing it from general app/compose tools, though it doesn't explicitly contrast against dokploy_docker or dokploy_docker_volume.

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?

Provides per-action conditions, e.g. networksToSync is for networks existing on the host but untracked, and import consumes names from networksToSync. It routes the agent onward for attachment ('Attach networks to workloads with dokploy_application update networkIds'). However it doesn't state exclusions or prerequisites (e.g. when not to use recreate vs resync beyond a single clause).

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 present, the description carries the full burden and it delivers the key safety trait up front: 'Read-only', implying no side effects. It also discloses the unfiltered global scope ('span every project', 'fleet-wide') and what each mode surfaces, setting expectations about breadth. However, the literal claim 'No parameters' is behaviorally misleading because the schema requires an `action` argument, which could cause an agent to attempt an invalid call.

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?

Roughly 75 words cover purpose, scope, all three mode semantics, when-to-use, and follow-up routing, front-loaded with 'Read-only fleet-wide rollups'. Every sentence earns its place except the short 'No parameters' phrase, which is both incorrect and confusing. The structure is otherwise tight and efficient.

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 three-mode read-only tool with no output schema and no annotations, the description covers what each mode returns, the global scope, and the navigation flow into detail tools. It doesn't specify the output shape beyond field hints (status, schedule, target), which is acceptable for an orientation tool. An agent has everything needed to choose a mode and invoke correctly.

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 fully compensates by explaining the meaning of each enum value — 'services', 'backups', 'domains' — and what each returns. The action-to-meaning mapping is clear enough for an agent to select the right value. The 'No parameters' sentence creates tension with the required `action` parameter, but the surrounding content resolves that ambiguity in practice.

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 purpose: read-only fleet-wide rollups spanning every project, used for orientation before drilling into a specific resource. It differentiates itself from siblings by naming the detail tools (dokploy_application, dokploy_domain, dokploy_backup) as follow-ups. Each action mode is tied to concrete output ('services: every application, compose service and database with its status'), so an agent knows exactly what the tool produces.

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 gives an explicit decision rule: use these first when asked 'what is running / what is exposed / what is backed up', then switch to the named sibling tools for detail and for changes. This directly tells the agent when to invoke this tool versus alternatives, leaving little to inference.

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 exist, so the description carries the full burden of behavioral disclosure. It only lists action-parameter mappings without mentioning side effects (e.g., remove is destructive, redeploy triggers a build), permission requirements, or return value behavior. This is a significant gap for mutating actions like remove and redeploy.

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 efficiently enumerates actions and their parameter usage using a structured list. It is front-loaded with the resource type and contains no filler, making it highly concise and scannable.

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?

The description covers the core action-to-parameter mapping but lacks details on return values, error behavior, and side effects. For a multi-action tool with no output schema and no annotations, this is a moderate gap that prevents full autonomous understanding.

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 adds crucial meaning by mapping each action to its required parameter (applicationId for list, previewDeploymentId for get/remove/redeploy, and title/description for redeploy). It stops short of stating whether parameters are required or optional per action, but the mapping is valuable.

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 identifies the resource as 'preview deployments' and enumerates four specific actions (list, get, remove, redeploy), clearly stating what the tool does. It also distinguishes this from sibling tools like dokploy_deployment by specifying 'per-PR / per-branch deploys off a parent application'.

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 'per-PR / per-branch deploys off a parent application' gives context for when this tool should be used, implying its niche. However, it does not explicitly compare with alternatives like dokploy_deployment or provide when-not-to-use guidance.

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?

The description discloses basic behavior for each action (e.g., list returns nested environments, remove deletes a project), but does not cover side effects, permission requirements, or idempotency. Since annotations are absent, the description carries full burden and provides minimal depth.

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 extremely concise, using a single sentence with colon-separated actions. Every word earns its place, and the structure is front-loaded with the purpose ('Manage projects') followed by a compact list of operations.

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 6 parameters, 1 required, and no output schema, the description covers the main actions and their key parameters but lacks details on optional parameters (e.g., description), output format, and edge cases. It is functional but not fully comprehensive.

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 significant meaning beyond the schema by mapping each action to required parameters (e.g., 'list: all' implies no parameters needed, 'duplicate: sourceEnvironmentId+name'). However, it omits details for some parameters like 'description' and 'duplicateInSameProject', leaving gaps despite 0% schema coverage.

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 'Manage projects' and enumerates each action (list, get, create, update, remove, duplicate) with specific parameter requirements, effectively distinguishing it from sibling tools that manage other entities like applications or databases.

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 implicitly guides usage through action enumeration (e.g., 'list: all' indicates when to use list), but lacks explicit guidance on when to choose this tool over alternatives or exclusion criteria, such as 'use dokploy_environment for environment-level operations'.

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 burden. It discloses the important behavior that 'A redeploy of the application is required for changes to take effect', which is valuable. However, it does not cover other behavioral aspects like error handling, idempotency, or authorization requirements, leaving gaps for a no-annotation context.

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 compact and front-loaded with the tool's purpose. It uses a list-like structure for actions, which is efficient. However, it is a single run-on sentence that could be better formatted for readability, but it earns a 4 for being concise and informative.

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 has 6 parameters, no annotations, and no output schema, the description covers the core functionality well: it lists all actions, required parameters, and the critical redeploy requirement. It does not explain return values, but for a simple CRUD tool this is acceptable. The description is sufficiently complete for an agent to use it effectively.

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 meaning beyond the schema by specifying which parameters are required for each action (create: regex+replacement+permanent+applicationId, update: redirectId+regex+replacement+permanent, etc.). This is not present in the schema for action, redirectId, and applicationId. Schema coverage is only 50%, but the description compensates by mapping actions to parameters.

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's purpose: 'Manage URL redirect rules on an application (Traefik regex/replacement)'. It identifies the resource (redirect rules), the context (application/Traefik), and the CRUD actions. This distinguishes it from sibling tools like dokploy_application or dokploy_domain.

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 context (URL redirects on an application) but does not explicitly state when to use this tool versus alternatives or when not to use it. It does list all sub-actions and their required parameters, which implies usage, but there is no explicit comparison to 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?

The description notes that the 'test' action does not persist, which is a behavioral trait. However, it does not disclose other behavioral details such as destructive nature of 'remove', authentication requirements, or rate limits. With no annotations, the description carries moderate transparency.

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 very concise, using a compact notation to convey action-parameter mappings. It front-loads the purpose and then lists actions efficiently. Every sentence contributes, though the terse style may reduce readability.

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 complexity (9 parameters, no output schema, no annotations), the description covers action-specific parameter requirements but lacks overall context such as return values, error handling, or authentication. It is adequate but not comprehensive.

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 low (22%), but the description adds value by mapping parameters to specific actions (e.g., 'create: registryName+username+password+registryUrl'). However, it does not explain the semantic meaning of individual parameters beyond the schema, leaving interpretation to the agent.

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 manages container registries for pulling private images, and enumerates actions. It is specific about the resource and verb, but does not explicitly differentiate from sibling tools beyond the name.

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. The description only lists actions with parameter hints, but does not provide criteria for selecting this tool over sibling tools like dokploy_docker or dokploy_settings.

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 does state that schedules run commands against resources, which implies execution behavior, but it does not disclose potential side effects (e.g., that runManually immediately executes the command, or that remove deletes an active schedule). The action list is descriptive but lacks explicit warnings or consequences, placing it at the minimum viable level.

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 dense, information-packed block with no filler. The first sentence states the core purpose, then actions are compactly listed with required parameter patterns. Every phrase earns its place, making it highly efficient for an AI agent to parse.

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 (17 parameters, 6 actions, no output schema), the description is reasonably complete. It covers all actions, required parameters, relationship between scheduleType and target IDs, and special list id value. Minor gaps exist (e.g., whether update is partial or full replacement, or error behavior), but overall it provides sufficient context 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 description coverage is only 41%, so the description must compensate. It effectively adds meaning by grouping parameters per action, clarifying parent-id semantics for list ('applicationId|composeId|serverId|dokploy-server'), and listing enum values (scheduleType, shellType). This goes beyond the raw schema and helps an agent assemble valid requests.

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 opens with a specific verb+resource: 'Manage cron schedules that run commands against applications, compose services, or servers.' It clearly distinguishes this tool from sibling tools (none of which mention schedules) and enumerates all supported actions (create, update, remove, get, list, runManually), leaving no ambiguity about scope.

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 explicit per-action parameter requirements (e.g., 'create: name+cronExpression+command (+ scheduleType and matching applicationId/composeId/serverId)'), which effectively tells an agent what to provide for each operation. It does not name sibling alternatives, but the scope of targets (applications, compose services, servers) is clear and no overlapping sibling exists, so this is strong guidance.

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 what getServices returns (applications, compose services, databases and their projects) and cautions to check before removal, which is genuine added context. But it says nothing about auth requirements, reversibility, what remove actually destroys, or error behavior for a tool containing destructive actions.

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?

Extremely compact, action-by-action with zero filler and the key constraint front-loaded. Structure is efficient, though the dense run-on formatting makes it slightly harder to scan than a bulleted breakdown would be.

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 nine-action, twelve-parameter tool with no annotations and no output schema, the description covers the calling mechanics well (which params per action, one return-content note, one caution). It is still thin on mutation semantics, permissions, and the undocumented dataPoints parameter, leaving meaningful gaps for such a complex 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 coverage is only 8%, so the description must compensate, and it does partially by mapping parameters to actions (create: name+ipAddress+port+username+sshKeyId+serverType, etc.). However, it omits the dataPoints parameter entirely and never explains the meaning or format of any parameter, so the compensation is incomplete.

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 tool is a multi-action server manager, and the description enumerates all nine actions with their parameters, making the resource (servers) and each operation concrete. 'Manage servers' alone is generic, but the per-action breakdown removes ambiguity about what the tool actually does and separates it from siblings like dokploy_ssh_key or dokploy_infrastructure.

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?

It gives an implicit when-to-use signal by mapping each action to its required params, and adds a real routing hint: '(check before removing a server)'. However, it never states when to prefer this tool over alternatives or when an action is inappropriate, so usage is only partially guided.

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 present, the description carries the full burden for behavioral disclosure. It does not warn that clean is destructive or that reload may interrupt services, nor does it explain permissions or side effects. The only behavioral nuance provided is the conditional serverId handling, which is useful but insufficient for a tool containing destructive and system-impacting operations.

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 extremely compact and front-loaded with 'System settings.' followed by action-specific details. Every phrase carries informational weight, with no fluff or repetition. The dense colon-separated format is efficient for an agent to parse.

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?

The description covers all actions and parameter dependencies, so an agent can likely invoke the tool correctly. However, there is no output schema and no annotations, and the description omits behavioral context such as destructive consequences and expected return values for operations like clean and reload. It is adequate 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?

Schema description coverage is 0%, so the description must compensate. It does by explaining each action and enumerating valid cleanType and reloadTarget values with conditional rules for serverId. A minor gap is that serverId itself is not explicitly defined beyond when it applies.

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 defines what the tool does: it exposes system settings operations such as health, version, IP, clean, and reload. Each action is paired with a concise verb and target, making the tool's scope understandable. However, it does not explicitly differentiate these operations from overlapping sibling tools like dokploy_server, info, or dokploy_docker.

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 gives clear conditional usage context: serverId is only honored for docker-related clean types and only for reload when the target is traefik. This helps an agent decide which parameters to include for each action. It does not explicitly compare this tool to sibling alternatives, but the parameter-level guidance is strong.

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 bears full responsibility. It states the tool 'manages' SSH keys but does not disclose that actions like 'remove' are destructive, that authorization is required, or any side effects. The automatic resolution of organizationId is a positive mention, but overall behavioral details are sparse.

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 paragraph that front-loads the main purpose and then lists actions concisely. Each sentence adds value, but the density could be slightly improved with clearer separation of actions.

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 8 parameters and 6 actions with no output schema, the description covers the action-parameter mappings but lacks details on return values, error handling, or parameter constraints. It is incomplete for an agent to reliably invoke the tool without additional knowledge.

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 25%, with descriptions only for 'type' and 'lastUsedAt'. The description maps parameters to actions (e.g., 'create: name+privateKey+publicKey, description?'), adding some meaning beyond the schema. However, it does not explain formats, constraints, or optional/required status for parameters in each action.

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 starts with 'Manage SSH keys' and explicitly lists all six actions (create, list, get, update, remove, generate) with their required parameters, making the tool's purpose and scope immediately clear. It distinguishes well from sibling tools by focusing on SSH key management.

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 lists actions and associated parameters, providing clear context for when to use each action. However, it does not offer guidance on when not to use the tool or alternatives, such as other methods for managing SSH keys.

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 well: it discloses that update REPLACES the provider (all four fields required even for a one-field change), that listSecretNames returns names only because no API reads values, and that provider credentials are never echoed back. Missing pieces are auth/permission requirements and rate-limit behavior, which keeps it out of the top band.

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?

One dense, front-loaded paragraph that opens with purpose and then walks the action list; nearly every clause carries information (defaults, caveats, disambiguation) rather than filler. It loses a point for being a single unbroken run-on block that is harder to scan than a short action-per-line structure would be.

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 7-parameter, 7-action tool with no annotations and no output schema, the description covers the essentials: action semantics, required fields per action, config discrimination, and return-value behavior for listSecretNames. Remaining gaps (permission scopes, exact list/get payload shape) are modest given the tool's complexity.

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 71%, and the description compensates well beyond it: it maps parameters to each action, documents the assignments shape ([{projectId, environmentIds?}]), and warns that infisical.projectId and scaleway.projectId are the provider's own project, not the Dokploy projectId. This cross-field disambiguation is genuine added meaning the schema only partially conveys.

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 the resource precisely (external secret-manager / vault configuration) and enumerates the exact operations it supports (list, get, create, update, remove, testConnection, listSecretNames) with the key parameter for each. This cleanly distinguishes it from every sibling dokploy_* tool, none of which deal with vault providers.

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?

It gives actionable routing guidance within the multi-action tool: testConnection takes a vaultProviderId for a saved provider or a raw config to validate credentials before saving, and update explicitly says 'run get first' because the API replaces the provider. What it lacks is any statement of when not to use this tool versus a sibling, but given no sibling overlaps the domain, the intra-tool guidance is the valuable part and it is present.

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 must disclose behavioral traits. It mentions the rclone-based nature, scheduling, the turnOff option to stop services during backup, and runManually for immediate triggers. However, it does not disclose potential side effects such as downtime implications of turnOff, the destructive nature of remove, or how keepLatestCount affects retention. It adds some meaningful context but not a full behavioral profile.

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 dense but efficiently communicates all key information without fluff. It uses a compact action-colon format that packs a lot of detail. However, it's a single block of text; a bulleted list would improve readability, but it remains reasonably structured and front-loaded with the core 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?

With 23 parameters, 6 actions, no output schema, and no annotations, the description does a solid job of covering the operational aspects. It explains each action's required parameters and the distinction from related tools. Missing elements include return value descriptions and specific behavior of each action (e.g., what get returns, what runManually does beyond 'trigger immediately'), but given the high complexity, the description is fairly 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?

The schema description coverage is only 22%, and the schema alone does not indicate which parameters apply to which action. The description compensates exceptionally well by explicitly mapping each action to its required and optional parameters (e.g., create needs name+volumeName+prefix+cronExpression+destinationId, list needs id+volumeBackupType). This is critical semantic guidance that the schema lacks.

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 it manages scheduled volume-level backups using rclone, and explicitly distinguishes it from dokploy_backup which does DB-native dumps. This specific verb+resource+scope fully clarifies what the tool does and differentiates it from its sibling.

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 explicitly contrasts this tool with dokploy_backup ('Distinct from dokploy_backup, which does DB-native dumps'), giving direct when-to-use/when-not-to-use guidance. It also enumerates the actions (create, update, remove, get, list, runManually) and the required parameters for each, effectively guiding the agent on how to invoke the tool correctly for different operations.

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?

The annotations already declare readOnlyHint=true, so the description's disclosure of a read operation is consistent. It adds value by specifying the exact return content (name, version, build commit, runtime, capability counts), which is not captured in the annotations. No behavioral contradictions or hidden 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 is front-loaded with the purpose ('Returns identity and build information for this server') and immediately lists the specific fields. Every word earns its place; there is no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and is read-only, the description fully covers what the agent needs to know: what it returns (identity and build info with listed fields). The context of sibling tools is clear, and no additional information is needed 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?

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to explain parameters since there are none. It adds no additional parameter information but none is required.

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 explicitly states the tool returns 'identity and build information for this server' and lists the specific fields (name, version, build commit, runtime, capability counts). This clearly distinguishes it from the sibling tools, which are all time-related 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 does not explicitly state when to use this tool versus alternatives. However, the sibling tools are all time-focused (get_current_time, convert_timezone, etc.), so the context implies this is the tool for server info. No explicit guidance on when not to use it is provided.

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