Server Quality Checklist

Tool Scores

• dokploy_dockerC
  2.9/5.0
  Behavior2/5

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

  No annotations exist, so the description must bear full burden. It lists actions like removeContainer and killContainer but does not disclose their destructive nature, side effects, or any prerequisites. The safety profile is opaque.

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

  Conciseness3/5

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

  The description is relatively short but uses parentheses and question marks in a way that may be confusing. It could be better structured (e.g., bullet points for methods). However, it is not overly verbose.

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

  Completeness2/5

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

  Given 7 parameters, no output schema, and no annotations, the description is incomplete. It lacks details on parameters like serverId and containerId, and does not mention return values. The method semantics are helpful but insufficient for full context.

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

  Parameters4/5

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

  Schema description coverage is low (29%). The description compensates by explaining method semantics (match, label, stack, service) and indicating optionality of serverId and containerId with '?'. This adds significant value beyond the schema.

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

  Purpose4/5

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

  The description states 'Docker container management' and lists specific actions (getContainers, restartContainer, etc.), making the tool's purpose clear. It distinguishes from siblings like dokploy_application or dokploy_backup, which focus on other resources.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus siblings or how to choose between actions (e.g., getContainers vs findContainers). Method semantics are described but not in a usage decision context.

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

• dokploy_serverC
  2.9/5.0
  Behavior2/5

  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.

  Conciseness4/5

  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.

  Completeness2/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• dokploy_domainB
  3.2/5.0
  Behavior2/5

  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 only lists action syntax without mentioning whether operations are destructive, idempotent, or require specific permissions. No details on side effects or error conditions.

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

  Conciseness3/5

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

  The description is a single sentence with colon-separated snippets for each action. It is concise but dense and hard to parse quickly. Better structuring (e.g., bullet points or sections) would improve readability.

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

  Completeness2/5

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

  With 8 actions and 15 parameters, no output schema, and no explanations for return values or behavior, the description is incomplete. For a complex multi-action tool, more detail is needed on what each action returns and under what conditions it succeeds or fails.

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

  Parameters3/5

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

  Schema description coverage is only 13%, but the description adds meaning by specifying which parameters are needed for each action (e.g., create requires host+applicationId|composeId(+serviceName)). However, many parameters like path, port, https, serverIp are not explained in the description, leaving gaps.

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

  Purpose5/5

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

  The description starts with 'Manage domains.' and lists all actions (create, list, get, update, delete, generate, canGenerateTraefikMe, validate) with parameter hints. It clearly identifies the tool as a domain manager, distinct from sibling tools managing other resources.

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

  Usage Guidelines3/5

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

  The description provides action-specific parameter requirements but does not offer guidance on when to use this tool versus alternatives (e.g., other dokploy tools). It implicitly covers usage per action, but lacks explicit when-to/when-not-to advice.

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

• dokploy_registryB
  3.2/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• dokploy_ssh_keyB
  3.3/5.0
  Behavior2/5

  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.

  Conciseness4/5

  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.

  Completeness2/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• dokploy_infrastructureB
  3.4/5.0
  Behavior2/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines2/5

  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.

• dokploy_preview_deploymentB
  3.4/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• dokploy_backupA
  3.5/5.0
  Behavior2/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• dokploy_environmentA
  3.5/5.0
  Behavior2/5

  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.

  Conciseness4/5

  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.

  Completeness2/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• dokploy_deploymentA
  3.7/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• dokploy_destinationA
  3.7/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• dokploy_mountsA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness3/5

  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.

  Completeness3/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• dokploy_projectA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• dokploy_redirectsA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• dokploy_settingsA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses the actions and parameter constraints (e.g., serverId only honored for certain clean types), but does not mention side effects (e.g., whether clean is destructive), authentication needs, rate limits, or other behavioral traits. Partial transparency but not comprehensive.

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

  Conciseness5/5

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

  The description is extremely concise, using a simple list format with minimal words. Every sentence provides essential information, and the structure front-loads the overall purpose ('System settings') followed by action-specific details. No fluff or redundancy.

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

  Completeness3/5

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

  Given the multi-action complexity, no output schema, and no annotations, the description covers actions and their parameters adequately but does not explain return values, error handling, or any post-conditions. For a system settings tool, more context on what to expect from each action would improve completeness.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate. It explains the enum values for cleanType and reloadTarget, and adds conditional logic for serverId. This adds significant meaning beyond the raw schema, though it could still clarify serverId's general purpose or other parameters like action itself.

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

  Purpose5/5

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

  The description clearly states 'System settings' and then enumerates specific actions (health, version, ip, clean, reload) with brief explanations. Each action has a distinct verb and resource, and the tool's purpose is easily distinguished from sibling tools (e.g., dokploy_application, dokploy_database) which focus on other domains.

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

  Usage Guidelines3/5

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

  The description implies when to use each action (e.g., 'check status' for health) but does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusion criteria or prerequisites. It lacks guidance on choosing between actions or when to delegate to other tools.

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

• dokploy_applicationA
  4.2/5.0
  Behavior5/5

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

  The description proactively discloses critical traits: get returns masked env summary (never values), deploy's first attempt may fail and should be retried immediately, setEnvVars performs read-modify-write with masked confirmation, and getEnvValuesUnsafe is explicitly flagged as unsafe with output going to logs. These go beyond the raw action names and are essential for safe invocation.

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

  Conciseness4/5

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

  The description is a dense but efficient reference, structured as action: parameters. It front-loads the purpose and then details each subaction without fluff. While long, it isn't verbose—each phrase is necessary for a 23-action tool. It earns its length, though a more structured format (e.g., bullets) could improve scannability.

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

  Completeness4/5

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

  The description covers return types and defaults for key actions (get, readLogs, getEnvKeys, setEnvVars, search), and explicitly warns about unsafe operations. However, some actions like cleanQueues, killBuild, and cancelDeployment are only named without behavioral details, and the description doesn't address common error responses or permission requirements. Overall, it is substantial for a tool with no output schema.

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

  Parameters5/5

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

  With 43 parameters and only 47% schema description coverage, the description compensates by mapping actions to required parameters (e.g., 'create: name+environmentId', 'move: applicationId+targetEnvironmentId') and adding domain context for fields like sourceType (explains github/git/docker options and limitations). It also clarifies the environment variable formats for saveEnvironment and setEnvVars, adding meaning beyond the schema.

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

  Purpose5/5

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

  The description opens with 'Manage applications' and then enumerates 23 specific actions (create, get, update, move, deploy, etc.) with their required parameters, making the tool's purpose and scope unambiguous. It clearly distinguishes from sibling tools like dokploy_project or dokploy_compose by focusing on application management.

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

  Usage Guidelines2/5

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

  The description provides a command list but no explicit guidance on when to choose this tool over sibling tools (e.g., dokploy_deployment, dokploy_compose). It doesn't state exclusions or alternatives, so the agent must infer usage from the tool name. There is clear context for each subaction, but no higher-level direction.

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

• dokploy_scheduleA
  4.2/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• dokploy_audit_logA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• dokploy_volume_backupA
  4.4/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• dokploy_composeA
  4.5/5.0
  Behavior5/5

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

  The description goes well beyond a simple summary: it warns that get returns 'masked env summary — never values', flags getEnvValuesUnsafe as 'UNSAFE escape hatch' with output going to the transcript, and notes merge/full-replace semantics. For a tool with no annotations, this is exemplary disclosure of side effects and risks.

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

  Conciseness4/5

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

  The description is dense and action-oriented, with each action listed compactly. It is longer than typical, but the length is justified by the 21 distinct actions. The format is a bit run-on but remains scannable; the opening sentence provides a clear anchor.

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

  Completeness4/5

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

  Given the tool's complexity (37 parameters, no output schema), the description covers many critical behaviors: masking, unsafe value retrieval, deployment failure caveat, and action-specific parameter requirements. It omits return details for most actions, but the coverage of safety and operation semantics is strong enough to prevent common misuse.

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

  Parameters4/5

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

  The description maps parameters to each action (e.g., create: name+environmentId, move: composeId+targetEnvironmentId), adding context beyond the raw schema. It also clarifies behavior like 'saveEnvironment: composeId+env (full replace)' and 'setEnvVars: composeId + set?/unset? (merge inside the server)'. However, with 37 params and 62% schema coverage, some params remain underspecified without description-level detail.

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

  Purpose5/5

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

  The description opens with 'Manage Docker Compose services' and then enumerates every action (create, get, update, delete, deploy, etc.), making the tool's scope and operations explicit. It clearly distinguishes from sibling tools by focusing specifically on Docker Compose services.

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

  Usage Guidelines4/5

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

  Provides concrete usage notes for several actions, e.g., 'loadServices: composeId (must deploy first)' and 'first deploy on new services may fail — retry immediately'. It does not explicitly name alternatives or when-not-to-use, but the action-specific prerequisites and caveats offer solid practical guidance.

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

• infoA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• dokploy_databaseA
  4.7/5.0
  Behavior5/5

  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 return behavior ('get: ... masked env summary — never values'), state change semantics ('saveEnvironment: env (full replace)'), and safety ('getEnvValuesUnsafe: UNSAFE escape hatch'). It also notes limitations like 'search ... not supported for libsql'.

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

  Conciseness5/5

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

  Although long, the description is dense and efficiently organized by action with colons and semicolons. Every sentence carries operational detail, and there is no redundant or promotional language.

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

  Completeness4/5

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

  The description is largely complete for a tool with 31 params and 17 actions: it groups parameters by action and engine and explains return and unsafe behaviors. However, a few schema parameters (cpuLimit, memoryLimit, serverId, command) are not explained anywhere, leaving gaps for update/create scenarios. Given the absence of an output schema and annotations, these omissions prevent a perfect score.

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

  Parameters5/5

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

  Schema coverage is only 45%, but the description compensates by explaining which parameters are required per action/engine (e.g., 'postgres/mysql/mariadb: REQUIRE databaseName+databaseUser', 'mongo: REQUIRES databaseUser (databaseName not used)') and clarifies the meaning of fields like set/unset for setEnvVars and q/limit/offset for search.

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

  Purpose5/5

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

  Description opens with 'Manage databases (postgres/mysql/mariadb/mongo/redis/libsql)', specifying the verb and resource. The 17 enumerated actions (create, get, update, move, start, stop, etc.) clarify the scope and distinguish it from sibling resource management tools like dokploy_application or dokploy_compose.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool (any database management operation) and breaks down per-action and per-engine requirements. However, it does not explicitly discuss alternatives or when not to use this tool (e.g., when managing applications or deployments), so it stops short of full exclusion guidance.

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