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 it well: it reveals that get returns a masked env summary and never values, saveEnvironment is a full replace, setEnvVars is a server-side read-modify-write with masked confirmation, and getEnvValuesUnsafe writes real values into the transcript/logs. It also exposes the first-deploy failure mode and the search-index limitation, which 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 appropriately sized for a 23-action tool, front-loaded with the resource name and using a consistent action: parameter pattern. Trivial grouped actions like start/stop/delete/markRunning/refreshToken/cleanQueues/killBuild/cancelDeployment are collapsed into one clause, and every sentence carries caveats or semantics rather than 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?

For a tool with no annotations and no output schema, this is remarkably complete: required IDs per action, env-var safety boundaries, log defaults, deploy retry behavior, and search limitations are all present. The remaining gaps are undefined return shapes for most actions and missing prerequisites for some update paths (e.g., sourceType github requiring repository+owner+branch), but the coverage is strong for the size.

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%, so the description compensates by mapping parameters to actions and adding semantics that are not in the schema: env KEY=VALUE full replace, set/unset upsert/remove behavior, traefikConfig omit-to-read, search fields, and log tail/since/search meaning. Still, the update action hand-waves some fields with 'etc.', and many numeric/resource fields remain unspecified in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies this as the application management dispatcher ('Manage applications') and enumerates every supported action: create, get, update, move, deploy, start/stop/delete, env operations, build type, traefik config, monitoring, logs, and search. It differentiates from sibling tools by noting the search index is narrower than dokploy_project/dokploy_overview and that it should be used to find a known service, not to inventory.

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 usage guidance for search, naming dokploy_project/dokploy_overview as better for inventory, and warns that the first deploy on new services may fail and should be retried immediately. It also flags getEnvValuesUnsafe as an unsafe escape hatch. It does not systematically compare against every sibling (e.g., dokploy_compose, dokploy_deployment) for overlapping operations, but the key routing decisions are covered.

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 provided, the description carries the full disclosure burden and excels at it: get 'never values' (masked summary), setEnvVars 'merge inside the server, masked confirmation only', saveEnvironment 'full replace', getEnvValuesUnsafe explicitly flagged 'UNSAFE' with output going to the tool transcript, and update/createEnvFile's side effect of writing a .env file beside the compose file. It also reveals the latent first-deploy failure mode and the search index's narrowness — exactly the behavioral knowledge an agent cannot derive 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?

For a 21-action dispatcher, the description is remarkably dense with zero filler — each action is compressed into a signature plus caveats, and the most important safety warnings are front-loaded within each segment. The weakness is purely structural: a single unbroken paragraph that is hard to scan; per-action line breaks or a bulleted layout would make it exemplary.

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 39 parameters, 21 actions, no annotations, and no output schema, the description covers the high-risk and high-confusion paths well: the unsafe env escape hatch, masking behavior, deployment retry semantics, full-replace vs merge distinctions, and a cross-tool pointer (dokploy_docker findContainers for readLogs discovery). The tail actions (cancelDeployment/cleanQueues/killBuild/refreshToken) are name-listed without any behavioral explanation, and return shapes are only specified for env-related and get actions, leaving other actions' outputs unspecified.

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 64% (mid-range), and the description's main contribution is the action→parameter routing — critical for a tool where only 'action' is required and the other 38 params are context-dependent. It adds real semantics beyond the schema ('createEnvFile? (also write a .env file next to the compose file)', serviceNetworks per-entry requirements, env as KEY=VALUE lines). However, it references 'composeFile' and 'containerId' which do not map cleanly to the schema (containerId is documented under the oddly-named 'description' property; composeFile doesn't exist as a property despite additionalProperties:false).

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 clause 'Manage Docker Compose services' plus the exhaustive action enumeration (create/get/update/deploy/delete/start/stop/move/readLogs/search, etc.) makes the tool's scope fully unambiguous. It stays at 4 rather than 5 because the verb 'Manage' is generic and it never explicitly names a sibling it is not (e.g., dokploy_application), relying instead on the 'compose' resource to differentiate.

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 embeds per-action usage constraints throughout, e.g., 'loadServices: composeId (must deploy first)', deploy's 'first deploy on new services may fail — retry immediately', and the search caveat that the API index is narrower than the project tree, explicitly recommending dokploy_project/dokploy_overview for inventory instead. However, there is no global when-to-use-vs-alternatives statement for the tool itself or for most actions; the agent must infer applicability from the action signatures.

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 provided, the description carries full responsibility and discloses important hidden behaviors: update REPLACES the provider, credentials are never echoed, provider reads return only id/name/providerType, and record type is restricted to A or CNAME. This is far beyond what the input schema alone reveals.

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 organized into 'Providers:' and 'Records:' sections, front-loaded with the overall purpose. Every sentence adds operational value, especially the behavioral caveats about replacement and credential non-echoing.

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-action tool with 10 parameters, no annotations, and no output schema, the description is remarkably complete, covering action-specific requirements, config construction, and provider read return shape. The only notable gap is that record-related list operations (listZones/listRecords) do not describe their return structure, but this is minor given the level of detail provided.

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 50%, but the description compensates by mapping each action to its required parameters, explaining the discriminated config union, clarifying that recordName is distinct from provider name, and noting ttl is optional. It also gives examples for content (IP vs target host), adding meaning 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?

States specific verb + resource: 'DNS provider configuration and DNS record management.' It enumerates all actions with their required parameters, making it unmistakable what the tool does and how it is differentiated from sibling tools like dokploy_vault_provider.

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 for each action, e.g. 'update (dnsProviderId+name+config)' and 'testConnection (dnsProviderId for a saved provider, or config to check credentials before saving)'. It does not explicitly mention when not to use the tool or alternatives, but the resource-specific name and sibling list make the use case 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 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 zero annotations, the description carries the full burden and it does disclose one meaningful trait: toggleEnable 'flips the enable flag blind', warning the agent that the end state is unknowable without a subsequent read. But it says nothing about the destructive side effects of delete, side effects of create (certificate generation, traefik config changes), authentication or permission needs, or idempotency. The single disclosed behavior is good, but coverage of the safety profile is thin.

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 dense with zero fluff; every phrase earns its place and the 'action: params' pair format is compact and scannable. It loses a point only for the single run-on paragraph structure — bullets or line separators would materially improve parsability for an agent picking out one action's requirements.

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?

Complexity is high — 9 actions, 16 parameters, no annotations, no output schema — and the description covers the action/parameter dispatch matrix well. But material gaps remain: return values are unspecified, the meaning of path/port/https/certificateType is unexplained, validate's behavior and error semantics are unknown, and preview domainType handling is absent. For a dispatcher of this size, 'manage domains' plus a param map is not fully self-sufficient.

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 19%, so the description must compensate — and it does, but only partially. It adds the critical action→parameter association matrix, including the conditional nuances '( +serviceName for compose)' and '(include composeId+serviceName for compose domains)', which the schema cannot express. However, parameters like path, port, https, serverIp, and certificateType remain unexplained in either source, and host is never defined as a domain name vs. IP.

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 'Manage domains' — a specific verb and resource — and then enumerates nine distinct sub-operations (create, list, get, update, delete, toggleEnable, generate, canGenerateTraefikMe, validate), giving a precise map of the tool's surface. It is clearly the domain manager among the dokploy_* siblings, though it never explicitly names a sibling it is not, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Each action is paired with the parameters it requires ('create: host+applicationId|composeId', 'get: domainId', etc.), giving an agent explicit invocation routing. The toggleEnable entry adds a strong preference rule — 'prefer update with enabled:true|false when you need a known end state' — which is genuine guidance. However, it never addresses when to use a sibling tool instead (e.g., dokploy_redirects, dokploy_dns_provider, dokploy_server), so cross-tool routing is left implicit.

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

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

No annotations are provided, so the description 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 provided, the description carries the behavioral burden. It discloses that inspect returns the raw Docker inspect payload and that recreate drops and re-adds the network, causing brief disconnection for attached services. It also clarifies the tracked-vs-untracked distinction for networksToSync. It could go further by stating whether remove deletes the Docker network or only removes it from Dokploy tracking, and by describing return shapes for list/get, but the most consequential side effects are covered.

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 organized by action type, with the 'Docker network management.' lead-in establishing scope immediately. It packs all action-parameter mappings, behavioral caveats, and cross-tool guidance into a compact set of sentences with no filler. The final cross-tool note is high-value and earns its place.

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

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

Given the tool's complexity—12 parameters, 8 actions, nested IPAM object, no output schema, and no annotations—the description is notably complete. It covers every action, the parameters each action needs, a destructive side effect, and the relationship between networksToSync and import. Minor gaps remain around the exact return values for list/get/remove and the precise semantics of remove, but nothing essential blocks correct tool selection or 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 33%, so the description must compensate, and it does. It maps actions to their relevant parameters, lists the create-specific parameters (driver bridge|overlay, internal, attachable, enableIPv4, enableIPv6, mtu 68-65535, ipam, serverId), and explains that import takes 'names (one or more names from networksToSync)'. This gives the agent actionable parameter semantics that the bare schema does not provide.

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 network management' and enumerates eight discrete actions: list, get, inspect, remove, recreate, create, networksToSync, and import. It specifies the resource types each acts on (serverId-scoped lists, networkId-scoped operations, names for import) and even distinguishes itself by pointing to dokploy_application/dokploy_compose for attaching networks, which separates it cleanly from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description maps each action to the exact parameter it needs: serverId for list/networksToSync/import, networkId for get/inspect/remove/recreate, and names for import. It explains when networksToSync is relevant ('networks that exist on the Docker host but are not yet tracked by Dokploy') and explicitly routes attachment work to sibling tools with 'Attach networks to workloads with dokploy_application update networkIds, or dokploy_compose update serviceNetworks.'

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, permissions, rate limits, return values, or what happens on success/failure. For actions like 'remove' or 'update', the behavior is not described. The description is purely parametric.

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 format to list actions and their parameters. It front-loads the purpose with 'Manage servers.' and then efficiently summarizes action-specific requirements. However, it could be better structured with bullet points or clearer separation between actions, but overall it earns its 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?

Given the complexity of 12 parameters and 8 actions with no output schema or annotations, the description is incomplete. It covers only basic parameter requirements per action, omitting details about return values, error states, pagination, or behavioral nuances. A more thorough description is needed for such a multi-action tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is only 8%, so the description must add meaning. While it does not explain each parameter's semantics, it groups required parameters per action (e.g., 'create: name+ipAddress+port+username+sshKeyId+serverType'), which adds value by indicating which parameters are relevant for which action. This partially compensates for the low schema coverage, but not entirely.

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 servers' which clearly identifies the resource. It then lists specific actions (list, get, create, update, remove, etc.) and their required parameters, providing a clear purpose. However, it does not differentiate from sibling tools like dokploy_infrastructure, which might also involve server management, but the action list makes it distinct 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 lacks any guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when not to use it. The list of actions with required parameters implies usage, but no explicit context or exclusions are provided.

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 provided, the description carries full responsibility for behavioral disclosure. It reveals the critical update-replaces-provider semantics requiring all four fields, the limitation that secret values are never readable, and that credentials are never echoed. These are material traits an agent must know before calling correctly.

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 organized, front-loaded with the tool's purpose and then moving through action semantics and caveats. It is longer than average, but every sentence carries operational value for a complex multi-provider, multi-action tool.

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

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

Given the tool's complexity, absent annotations, and absent output schema, the description does a strong job: it covers action semantics, required parameter groupings, provider-type discrimination, assignment meaning, and secret-value limitations. It still leaves some operational detail to the schema (defaults, exact fields per provider), but those are already structed, so the description is nearly complete on its own.

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 schema: it explains that config is discriminated by providerType, clarifies the dangerous ambiguity between provider-owned projectId and Dokploy assignment projectId, and defines assignments as Dokploy project/environment scopes. This directly compensates for the schema's under-described nested fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as managing external secret-manager (vault) providers and enumerates every action (list, get, create, update, remove, testConnection, listSecretNames). This makes the resource and verb set unambiguous, and the 'vault' resource clearly differentiates it from sibling tools like dns_provider or registry.

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 clear practical guidance for selecting and sequencing operations: run get before update, use testConnection with config before saving, and note that listSecretNames returns names only. It does not explicitly compare against sibling tools, but the resource scope makes the intended use obvious and the in-tool action 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 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?

Annotations already declare readOnlyHint: true, so the description adds value by detailing the exact fields returned (name, version, build commit, runtime, capability counts). There is no contradiction, and the description provides useful behavioral context beyond the annotation.

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

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

The description is a single sentence with no waste. It front-loads the purpose ('Returns...') and lists the included fields concisely. Every word earns its place.

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

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

Despite lacking an output schema, the description sufficiently explains the return values by listing the fields. With zero parameters and a simple purpose, the description is complete for the agent to understand what the tool does and what it returns.

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 the schema coverage is 100%. With no parameters, the description does not need to explain parameter semantics. A baseline of 4 is appropriate as the description adds no parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns identity and build information (name, version, build commit, runtime, capability counts) for the server. This is a specific verb+resource and distinguishes it from siblings which focus on managing specific resources like applications, databases, etc.

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 context is clear: use this tool to retrieve server metadata. While it doesn't explicitly mention when not to use it or name alternatives, the purpose is straightforward and self-explanatory for such a simple information retrieval tool.

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