Server Quality Checklist

Tool Scores

• dokploy_ai_deployD
  1.3/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond this. It doesn't explain what 'deploy' entails (e.g., creates resources, starts services), potential side effects, authentication needs, or rate limits. With annotations covering basic hints, the description fails to add meaningful value.

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

  Conciseness2/5

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

  The description is under-specified, not concise. It wastes space on a redundant header '[ai] ai.deploy (POST)' and a bare parameter list without meaningful context. It lacks a clear purpose statement upfront, making it inefficient for quick understanding.

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

  Completeness1/5

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

  Given the complexity (9 parameters with nested arrays, no output schema, and annotations only providing basic hints), the description is severely incomplete. It doesn't explain what the tool does, how to use parameters, what happens on deployment, or what to expect in return, making it inadequate for safe and effective use.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description only lists parameter names and types without explaining their purpose, expected formats (e.g., what 'dockerCompose' should contain, how 'envVariables' are formatted), or relationships. This leaves 9 parameters, including complex arrays like 'domains' and 'configFiles', completely unexplained.

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

  Purpose1/5

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

  The description is a tautology that merely restates the tool name 'ai.deploy' and lists parameters without explaining what the tool actually does. It fails to specify the verb (e.g., deploy an AI model, application, or service) or the resource being deployed, and doesn't distinguish it from sibling tools like 'dokploy_ai_create' or 'dokploy_application_deploy'.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or exclusions, leaving the agent with no information to decide between this and similar deployment tools in the sibling list.

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

• dokploy_application_updateD
  1.3/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which indicate this is a non-destructive, idempotent mutation. The description adds no behavioral context beyond these annotations—no information about permissions needed, rate limits, side effects, or what happens when fields are updated. With annotations covering basic safety, the description fails to add meaningful value.

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

  Conciseness2/5

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

  While the description is technically concise in terms of word count, it is poorly structured and under-specified. It wastes space on a raw parameter dump instead of providing meaningful prose. The information is not front-loaded with purpose or usage, making it inefficient for an agent to parse.

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

  Completeness1/5

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

  Given the high complexity (97 parameters, 0% schema coverage, no output schema) and the absence of annotations explaining behavioral details, the description is severely incomplete. It fails to explain what an 'application' is in this context, how updates are applied, what the response looks like, or any error conditions. For a mutation tool of this scale, the description is wholly inadequate.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning none of the 97 parameters have descriptions in the schema. The description merely lists parameter names and types without explaining their purpose, relationships, or usage. For a tool with 97 parameters, this is completely inadequate and provides no semantic understanding beyond what the schema already indicates through type constraints.

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

  Purpose1/5

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

  The description is a tautology that merely restates the tool name 'application.update' without explaining what it does. It provides no meaningful verb+resource statement or differentiation from sibling tools like 'dokploy_application_create' or 'dokploy_application_one'.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description offers no context about prerequisites, when this update operation is appropriate, or how it differs from other application-related tools in the sibling list.

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

• dokploy_compose_updateD
  1.3/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no behavioral context beyond what annotations already declare. It doesn't explain what 'update' entails (e.g., partial vs. full updates, side effects, permissions required, or response format). For a mutation tool with 44 parameters, this is inadequate.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently informative. It wastes space on a parameter list that belongs in the schema, without adding explanatory value. The structure lacks a clear purpose statement upfront, making it difficult to parse.

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

  Completeness1/5

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

  Given the high complexity (44 parameters, mutation operation), zero schema description coverage, no output schema, and rich annotations, the description is completely inadequate. It fails to explain what the tool does, how to use it, what parameters mean, or what to expect in return. This leaves critical gaps for agent understanding.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning no parameters have descriptions in the schema. The description provides only a raw parameter list without any explanation of what each parameter means, their relationships, or how they affect the update. With 44 parameters (many with unclear purposes like 'suffix', 'randomize', or various git provider fields), this leaves the agent completely in the dark.

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

  Purpose1/5

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

  The description is a tautology that merely restates the tool name and HTTP method without explaining what it does. It provides no verb+resource combination, no indication of what a 'compose' is in this context, and no differentiation from sibling tools like dokploy_compose_create or dokploy_compose_delete.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or when not to use it. With many sibling compose tools (create, delete, deploy, etc.), this lack of guidance is particularly problematic.

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

• dokploy_gitea_createD
  1.3/5.0
  Behavior2/5

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

  The description provides no behavioral information beyond what's in the annotations. While annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint, the description doesn't add any context about what 'create' actually means, what gets created, authentication requirements, error conditions, or side effects. However, it doesn't contradict the annotations.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently structured. It wastes space on a redundant title line and provides no actual description content - just a parameter list that duplicates information already available in the schema. The structure doesn't help an AI agent understand the tool.

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

  Completeness1/5

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

  For a creation tool with 15 parameters, no output schema, and complex sibling relationships (multiple gitea_* tools), this description is completely inadequate. It provides no information about what's being created, success/failure conditions, return values, or how this tool relates to the broader system context.

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

  Parameters1/5

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

  With 0% schema description coverage and 15 parameters (13 optional, 2 required), the description merely lists parameter names without any semantic explanation. It provides no information about what each parameter means, their relationships, or how they affect the creation operation. This fails to compensate for the complete lack of schema descriptions.

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

  Purpose1/5

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

  The description is essentially a tautology that restates the tool name 'dokploy_gitea_create' as '[gitea] gitea.create (POST)' without explaining what it actually does. It provides no verb or resource specification beyond the name, making it impossible to understand its purpose from the description alone.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description contains only a parameter list with no contextual information about prerequisites, appropriate use cases, or relationships to sibling tools like other gitea_* tools.

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

• dokploy_mongo_updateD
  1.3/5.0
  Behavior2/5

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

  Annotations indicate the tool is not read-only (readOnlyHint: false), not destructive (destructiveHint: false), idempotent (idempotentHint: true), and open-world (openWorldHint: true). The description adds no behavioral context beyond these annotations—it doesn't explain what 'update' entails (e.g., partial vs. full updates, side effects, authentication needs, or rate limits). However, it doesn't contradict the annotations, so it's not a contradiction, but it fails to provide additional useful information for a mutation tool.

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

  Conciseness2/5

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

  The description is poorly structured—it starts with a redundant line '[mongo] mongo.update (POST)' and then dumps a long, unformatted list of parameters without grouping or explanation. This is not concise; it's under-specified and cluttered, failing to front-load key information. The parameter list adds bulk without value, as it doesn't enhance understanding beyond the schema.

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

  Completeness1/5

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

  Given the tool's complexity (31 parameters, mutation operation, no output schema, and 0% schema description coverage), the description is severely incomplete. It doesn't explain the tool's purpose, usage, behavioral traits beyond annotations, or parameter meanings. For a tool that updates MongoDB resources in a deployment context, this lack of information makes it inadequate for effective agent use.

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

  Parameters1/5

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

  The description lists 31 parameters with basic types but adds no semantic meaning beyond what's in the input schema. With 0% schema description coverage, the schema lacks descriptions for all parameters, and the description doesn't compensate—it merely repeats parameter names without explaining their purposes (e.g., what 'mongoId' refers to, how 'applicationStatus' affects the update, or what 'replicaSets' does). This leaves parameters largely undocumented.

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

  Purpose1/5

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

  The description is essentially a tautology that restates the tool name 'dokploy_mongo_update' as '[mongo] mongo.update (POST)', providing no meaningful explanation of what the tool actually does. It fails to specify what resource is being updated (e.g., a MongoDB database instance, configuration, or deployment) or what the update operation entails, making it impossible to distinguish from sibling tools like 'dokploy_mongo_create' or 'dokploy_mongo_deploy'.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., an existing MongoDB resource to update), appropriate contexts, or comparisons to sibling tools such as 'dokploy_mongo_create' for initial setup or 'dokploy_mongo_deploy' for deployment actions. This leaves the agent with no usage context.

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

• dokploy_notification_createTelegramD
  1.5/5.0
  Behavior3/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description does not contradict these annotations (it doesn't claim read-only or idempotent behavior). However, it adds no behavioral context beyond what annotations provide—no explanation of what 'create' entails (e.g., whether it persists a configuration, sends a test message, requires specific permissions), rate limits, or error conditions. With annotations covering basic hints, the description meets a minimal baseline but adds no extra value.

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

  Conciseness2/5

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

  While concise, the description is under-specified rather than efficiently informative. It wastes space on a redundant header and a bare parameter list that adds no semantic value. A truly concise description would replace the parameter list with meaningful explanation of the tool's purpose and usage, making every sentence earn its place—which this does not do.

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

  Completeness1/5

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

  Given the complexity (11 required parameters, no output schema, 0% schema coverage), the description is severely incomplete. It does not explain what the tool does, when to use it, what the parameters mean, or what to expect upon success/failure. For a creation tool with many boolean flags and authentication parameters, this leaves the agent with insufficient information to use the tool correctly.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning none of the 11 parameters have descriptions in the schema. The description merely lists parameter names and types without explaining what they mean (e.g., what 'appBuildError' controls, what 'botToken' is for, what 'messageThreadId' does). This fails to compensate for the complete lack of schema documentation, leaving parameters entirely unexplained.

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

  Purpose1/5

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

  The description is essentially a tautology that restates the tool name with minimal additional information. It states '[notification] notification.createTelegram (POST)' which merely repeats the name and adds the HTTP method, but provides no meaningful explanation of what the tool actually does (e.g., creating a Telegram notification configuration for specific events in Dokploy). It fails to distinguish this tool from its many sibling notification tools (e.g., createDiscord, createEmail).

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or comparison with sibling tools like dokploy_notification_createDiscord or dokploy_notification_createEmail. An agent would have no idea when this specific Telegram notification tool is appropriate.

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

• dokploy_notification_updateEmailD
  1.5/5.0
  Behavior3/5

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

  The description adds no behavioral context beyond what annotations provide. Annotations indicate this is a non-destructive, idempotent, open-world update operation (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description doesn't add any information about authentication requirements, rate limits, side effects, or what constitutes a successful update. However, it doesn't contradict the annotations either.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently structured. The parameter listing is presented as raw data without meaningful organization or prioritization. The description fails to front-load the most critical information about the tool's purpose, making it inefficient for agent decision-making despite its brevity.

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

  Completeness1/5

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

  For a complex update tool with 17 parameters, no output schema, and 0% schema description coverage, the description is completely inadequate. It provides no information about what the tool updates, what the expected response format is, what validation occurs, or how to interpret the various boolean flags. The description fails to compensate for the lack of structured documentation.

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

  Parameters1/5

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

  With 17 parameters and 0% schema description coverage, the description carries the full burden of explaining parameter meanings. It merely lists parameter names and types without any explanation of what each parameter controls (e.g., what 'appBuildError' boolean toggles, what 'serverThreshold' monitors, what 'smtpServer' should contain). This leaves all 17 parameters semantically undefined despite the high parameter count.

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

  Purpose1/5

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

  The description is essentially a tautology that restates the tool name ('notification.updateEmail') with a method annotation ('POST'). It provides no meaningful explanation of what the tool actually does - whether it updates email notification settings, modifies email templates, or changes SMTP configuration. The description fails to distinguish this tool from its many notification-related siblings in the list.

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

  Usage Guidelines1/5

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

  The description provides zero guidance on when to use this tool versus alternatives. With numerous sibling tools like 'dokploy_notification_createEmail', 'dokploy_notification_updateCustom', 'dokploy_notification_updateDiscord', etc., there's no indication of when this specific email update tool should be selected over other notification update tools or when it's appropriate versus creating a new notification.

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

• dokploy_notification_updateNtfyD
  1.5/5.0
  Behavior3/5

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

  The description provides no behavioral information beyond what the annotations already declare (non-read-only, non-destructive, idempotent, open-world). It does not add context about what gets updated, authentication needs, rate limits, or side effects. However, it does not contradict the annotations, so it meets the lower bar with annotations present but adds minimal value.

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

  Conciseness2/5

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

  While the description is brief, it is under-specified rather than concise. The first line is redundant (restating name and POST method), and the parameter list is a raw dump without organization or meaningful context. It lacks front-loaded purpose and wastes space on obvious information without adding value.

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

  Completeness1/5

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

  Given the tool's complexity (14 parameters, mutation operation), the description is severely incomplete. It lacks purpose, usage guidelines, parameter meanings, and behavioral context. With no output schema and minimal annotations, the description fails to provide the necessary information for an agent to understand or correctly invoke this tool.

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

  Parameters1/5

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

  The description only lists parameter names and types without any semantic explanation. With schema description coverage at 0% and 14 parameters (2 required), the description fails to compensate by explaining what each parameter means (e.g., what 'appBuildError' controls, what 'priority' values are valid, what 'ntfyId' refers to). This leaves parameters largely undocumented.

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

  Purpose1/5

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

  The description is a tautology that merely restates the tool name and HTTP method. It provides no information about what the tool actually does (e.g., updating an Ntfy notification configuration in Dokploy). The description fails to specify the verb (update) and resource (Ntfy notification) clearly, making it impossible to understand the tool's purpose.

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

  Usage Guidelines1/5

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

  The description offers no guidance on when to use this tool versus alternatives. Given the sibling tools include multiple notification-related tools (e.g., dokploy_notification_createNtfy, dokploy_notification_updateCustom, dokploy_notification_one), there is no indication of when this specific update tool is appropriate or what distinguishes it from other notification tools.

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

• dokploy_redis_updateD
  1.5/5.0
  Behavior3/5

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

  Annotations indicate this is a non-destructive, idempotent update operation (readOnlyHint=false, destructiveHint=false, idempotentHint=true), which the description does not contradict. However, the description adds no behavioral context beyond what annotations provide, such as side effects, authentication requirements, or rate limits, leaving a moderate gap in transparency.

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

  Conciseness2/5

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

  The description is inefficiently structured as a raw parameter list without a clear purpose statement, making it front-loaded with irrelevant details. While concise in length, it wastes space on redundant information (parameter names) instead of providing actionable guidance, leading to poor usability.

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

  Completeness1/5

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

  Given the tool's complexity (29 parameters, mutation operation, no output schema), the description is severely incomplete. It lacks essential context such as the tool's purpose, usage scenarios, parameter explanations, and expected outcomes, failing to compensate for the absence of an output schema and low schema coverage.

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

  Parameters1/5

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

  With 0% schema description coverage and 29 parameters, the description merely lists parameter names without explaining their purpose, constraints, or relationships. It fails to add any semantic meaning beyond the schema, such as what 'redisId' refers to or how optional fields like 'dockerImage' affect the update, making parameter understanding inadequate.

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

  Purpose1/5

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

  The description is a tautology that merely repeats the tool name 'redis.update' and lists parameters without stating what the tool actually does. It fails to specify the action (e.g., update Redis instance configuration) or distinguish it from sibling tools like 'dokploy_redis_create' or 'dokploy_redis_stop'.

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

  Usage Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., requires an existing Redis instance), typical use cases, or comparisons to sibling tools such as 'dokploy_redis_create' for creation or 'dokploy_redis_deploy' for deployment.

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

• dokploy_notification_createResendD
  1.6/5.0
  Behavior2/5

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

  The description provides no behavioral information beyond what's in the annotations. Annotations indicate this is a non-readonly, non-destructive, non-idempotent operation with open-world semantics, but the description doesn't add any context about what 'createResend' actually does behaviorally - whether it sends notifications immediately, queues them, what happens on failure, or what the expected response looks like. For a tool with 11 required parameters and no output schema, this is a significant gap.

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

  Conciseness3/5

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

  The description is technically concise - just a header and parameter list - but this conciseness comes at the cost of being severely under-specified. While there's no wasted text, the structure provides no meaningful explanation of the tool's purpose or usage. The parameter list is presented but without any explanatory context, making it minimally useful despite being brief.

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

  Completeness1/5

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

  Given the complexity (11 required parameters, no output schema, 0% schema description coverage) and the rich ecosystem of sibling tools, this description is completely inadequate. It doesn't explain what the tool does, when to use it, what the parameters mean, what behavior to expect, or what the output might be. For a notification tool with multiple configuration options among many alternatives, this description fails to provide the minimal context needed for an AI agent to use it correctly.

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

  Parameters2/5

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

  The description simply lists parameter names and types without explaining what they mean or how they relate to each other. With 0% schema description coverage and 11 required parameters (including 7 boolean flags for different event types, plus name, apiKey, fromAddress, and toAddresses), the description fails to explain what these parameters control. It doesn't clarify what 'appBuildError', 'databaseBackup', etc. represent, or how the boolean flags interact with the notification creation/resending behavior.

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

  Purpose1/5

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

  The description is essentially a tautology that restates the tool name 'notification.createResend' with 'POST' added. It provides no meaningful explanation of what the tool actually does - whether it creates a notification, resends an existing one, or configures notification settings. The description fails to distinguish this tool from its many sibling notification tools like createEmail, createSlack, etc.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. With 11 sibling notification tools (createEmail, createSlack, createDiscord, etc.), there's no indication of what makes this 'Resend' tool different or when it should be chosen over other notification channels. No context about prerequisites, dependencies, or appropriate use cases is provided.

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

• dokploy_user_createApiKeyD
  1.6/5.0
  Behavior2/5

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

  Annotations indicate this is a write operation (readOnlyHint: false) that's non-destructive and non-idempotent. The description adds no behavioral context beyond what annotations provide - no information about authentication requirements, rate limits, what happens on success/failure, or how the API key is returned. With annotations covering basic safety, the description adds minimal value.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently informative. The parameter listing is structured but provides no meaningful context. The description wastes space on obvious formatting ('POST', bullet points) without adding explanatory value.

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

  Completeness1/5

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

  This is a complex mutation tool with 10 parameters, nested objects, no output schema, and 0% schema description coverage. The description completely fails to provide necessary context about what the tool does, how to use parameters, what it returns, or behavioral considerations. It's inadequate for a tool of this complexity.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning none of the 10 parameters have descriptions in the schema. The description merely lists parameter names and types without explaining what they mean (e.g., what 'expiresIn' units are, what 'metadata' contains, how rate limiting parameters interact). This fails to compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description restates the tool name ('user.createApiKey') and lists parameters but doesn't explain what the tool actually does. It's a tautology - it doesn't specify that this creates an API key for a user, what the key is used for, or how it differs from sibling tools like 'dokploy_user_generateToken'.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description provides no context about prerequisites, when this should be used instead of other user-related tools, or any usage constraints.

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

• dokploy_compose_disconnectGitProviderD
  1.7/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds that it's a POST request, which aligns with non-readOnly. However, it doesn't explain what 'disconnect' actually means behaviorally - whether it removes configuration, stops synchronization, affects running services, or requires specific permissions. For a mutation tool with minimal annotation coverage of behavioral traits, this leaves significant gaps in understanding the actual impact.

  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 extremely brief - just two lines showing the tool path and listing the parameter. While this is concise, it's under-specified rather than efficiently informative. The structure is clear but lacks the substantive content needed for a tool description. It doesn't waste words, but also doesn't provide enough information to be truly helpful.

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

  Completeness1/5

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

  For a mutation tool that disconnects something (potentially affecting system behavior), with no output schema, 0% parameter documentation, and minimal annotations, this description is completely inadequate. It doesn't explain what gets disconnected, why one would use it, what the consequences are, or what to expect as a result. The agent would have to guess about both the tool's purpose and its effects.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning the single parameter 'composeId' has no documentation in the schema. The description merely lists the parameter name without explaining what a composeId is, where to find it, what format it expects, or what happens if an invalid ID is provided. The description fails to compensate for the complete lack of schema documentation, leaving the parameter essentially undocumented.

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

  Purpose2/5

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

  The description states 'compose.disconnectGitProvider (POST)' which repeats the tool name and adds HTTP method, but doesn't explain what 'disconnectGitProvider' actually does. It doesn't specify what resource is being disconnected from what, or what the effect is. The description is essentially a tautology that restates the tool name with minimal additional context.

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

  Usage Guidelines1/5

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

  The description provides zero guidance on when to use this tool versus alternatives. There are sibling tools like 'dokploy_application_disconnectGitProvider' and various 'saveGitProvider' tools, but no indication of when this compose-specific version should be used versus the application version or when reconnection might be needed. No prerequisites, conditions, or exclusions are mentioned.

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

• dokploy_compose_processTemplateD
  1.7/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation, but the description adds no behavioral context beyond what annotations already provide. It doesn't explain what 'processing' entails, whether it's a transformation or validation, what side effects occur, or what the expected outcome is. For a mutation tool (readOnlyHint=false), this lack of behavioral description is a significant gap.

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

  Conciseness3/5

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

  The description is extremely brief (two lines) with no wasted words, but this brevity comes at the cost of being under-specified. While structured with the tool path and parameter list, it lacks the substantive content needed for understanding. It's concise but inadequately informative.

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

  Completeness1/5

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

  Given this is a mutation tool (readOnlyHint=false) with 2 undocumented parameters (0% schema coverage), no output schema, and no behavioral description, the description is completely inadequate. It fails to explain what the tool does, when to use it, what the parameters mean, or what to expect as a result. The annotations provide some safety profile, but the description adds almost no value.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning neither parameter has any documentation in the schema. The description only lists parameter names ('base64', 'composeId') without explaining what they represent, what format 'base64' should contain, what a 'composeId' refers to, or how they interact. This provides essentially no semantic value beyond the bare parameter names already visible in the schema.

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

  Purpose2/5

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

  The description merely restates the tool name with minimal context ('[compose] compose.processTemplate (POST)'), providing no specific verb or resource explanation. It doesn't clarify what 'processTemplate' means or how it differs from sibling compose tools like 'dokploy_compose_deployTemplate' or 'dokploy_compose_getConvertedCompose'. This is essentially a tautology of the name with HTTP method added.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description provides no context about prerequisites, typical use cases, or how it relates to other compose operations. With many sibling tools in the compose category, this leaves the agent guessing about appropriate selection.

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

• dokploy_compose_startD
  1.7/5.0
  Behavior2/5

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

  Annotations provide basic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), but the description adds almost no behavioral context beyond what's already in annotations. The description doesn't explain what 'start' means operationally - whether it starts a stopped compose, initiates a deployment, or performs some other action. No information about side effects, error conditions, or operational characteristics is provided. However, there's no contradiction with annotations.

  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 technically concise with just two lines, but this conciseness comes at the cost of being severely under-specified. The structure shows the HTTP method and lists the parameter, but the information is presented without proper context or explanation. While not verbose, it fails to provide necessary information that would help an agent understand and use the tool effectively.

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

  Completeness1/5

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

  Given that this is a mutation tool (readOnlyHint=false) with no output schema, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what the parameter means, what happens when invoked, or what the expected outcome is. The combination of poor description, 0% schema coverage, and no output schema leaves the agent with insufficient information to use this tool correctly.

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

  Parameters1/5

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

  The description lists 'composeId (string, required)' but provides zero semantic context about what a composeId is, where to find it, or what format it should have. With 0% schema description coverage and only one parameter, the description fails to compensate for the complete lack of schema documentation. The parameter is mentioned but not explained, leaving the agent with no meaningful guidance.

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

  Purpose2/5

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

  The description states '[compose] compose.start (POST)' which is a tautology that restates the tool name and HTTP method without explaining what the tool actually does. It mentions 'compose' but doesn't specify what a compose is in this context or what 'start' means operationally. The description fails to provide a clear verb+resource statement that distinguishes this tool from its siblings like 'dokploy_compose_stop' or 'dokploy_compose_deploy'.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple related compose tools (create, delete, deploy, stop, etc.) but no indication of when 'start' is appropriate versus 'deploy' or other operations. No prerequisites, conditions, or contextual usage information is provided.

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

• dokploy_mongo_moveD
  1.7/5.0
  Behavior2/5

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

  Annotations indicate this is not read-only, not destructive, not idempotent, and open-world. The description adds no behavioral context beyond what annotations provide—it doesn't explain what 'move' entails (e.g., migration, relocation, transfer between environments), potential side effects, permissions required, or rate limits. With annotations covering basic hints, the description fails to add meaningful behavioral insight.

  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 concise but under-specified—it's a single line with a parameter list, which is efficient but lacks necessary detail. While not verbose, it doesn't front-load critical information about the tool's purpose. The structure is minimal but could be improved with a clearer opening statement.

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

  Completeness1/5

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

  Given the complexity of a 'move' operation (likely involving database migration or environment transfer), the description is severely incomplete. With no output schema, 0% schema description coverage, and annotations that only provide basic hints, the description fails to explain what the tool does, its behavior, parameters, or expected outcomes. It leaves critical gaps for agent understanding.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description merely lists parameter names (mongoId, targetEnvironmentId) without explaining what they represent (e.g., IDs of MongoDB instances and target environments), their format, or valid values. It adds no semantic meaning beyond the bare parameter names, failing to compensate for the lack of schema documentation.

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

  Purpose2/5

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

  The description restates the tool name and title ('mongo.move') without explaining what 'move' means in this context. It lists parameters but doesn't specify what resource is being moved (e.g., a MongoDB database instance, container, or data). This is essentially a tautology of the name/title with minimal added value.

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

  Usage Guidelines1/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. Sibling tools include other 'move' operations (e.g., dokploy_application_move, dokploy_compose_move, dokploy_mariadb_move), but the description doesn't differentiate this MongoDB-specific move from those or explain prerequisites like whether the source must be stopped. No usage context is provided.

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

• dokploy_mysql_rebuildD
  1.7/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false (non-read operation), destructiveHint=false (non-destructive), idempotentHint=false (non-idempotent), and openWorldHint=true (open-world). The description adds no behavioral context beyond these annotations, such as what 'rebuild' entails (e.g., downtime, data persistence, permissions required). With annotations covering basic safety, the description fails to add meaningful value, but does not contradict annotations.

  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 concise with two lines, but it is under-specified rather than efficiently informative. The first line '[mysql] mysql.rebuild (POST)' is redundant with the name/title, and the parameters list is minimal. While not verbose, it lacks substantive content, making it inefficient in conveying necessary information.

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

  Completeness1/5

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

  Given the tool's complexity (a non-read, non-destructive, non-idempotent operation with open-world hint), the description is severely inadequate. It lacks details on what 'rebuild' does, expected outcomes, error conditions, or side effects. With no output schema and low parameter coverage, the description fails to provide a complete context for safe and effective use.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description only lists 'mysqlId' as a parameter without explaining its semantics (e.g., what a MySQL ID is, where to find it, format constraints). For a single required parameter with no schema documentation, the description does not compensate, leaving the parameter's meaning and usage unclear.

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

  Purpose2/5

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

  The description '[mysql] mysql.rebuild (POST)' is tautological, essentially restating the tool name with minimal context. It mentions 'mysql' and 'rebuild' but lacks a specific verb-resource combination explaining what 'rebuild' entails (e.g., recreating a MySQL database instance, resetting configurations). It does not distinguish from sibling tools like dokploy_mysql_reload or dokploy_mysql_remove, leaving the purpose vague.

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

  Usage Guidelines1/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 provides no context, prerequisites, or exclusions. Given sibling tools like dokploy_mysql_reload (for reloading) and dokploy_mysql_remove (for deletion), the lack of differentiation is misleading, as an agent cannot infer appropriate usage scenarios.

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

• dokploy_notification_createGotifyD
  1.7/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond what annotations already provide. For a creation tool with no output schema, the description should explain what happens on success (e.g., returns a notification ID), what permissions are needed, or whether this triggers notifications immediately. Without annotations covering these aspects, the description carries the burden but provides nothing.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently structured. It wastes the first line repeating the tool name and HTTP method, then provides a bare parameter list without grouping or explanation. The structure doesn't front-load purpose or usage, making it inefficient for agent comprehension despite its brevity.

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

  Completeness1/5

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

  For a complex creation tool with 11 required parameters, no output schema, and no annotations covering behavioral details, the description is completely inadequate. It doesn't explain what the tool creates, what the parameters mean, what happens on success/failure, or how it relates to the notification system. Given the rich sibling context and complete lack of structured documentation, this description provides almost no useful information.

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

  Parameters2/5

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

  With 0% schema description coverage and 11 required parameters, the description merely lists parameter names and types without explaining their meaning. It doesn't clarify what 'appBuildError', 'databaseBackup', etc. represent (likely event triggers), what 'priority' values mean, what 'decoration' does, or how 'serverUrl' and 'appToken' relate to Gotify configuration. The description fails to compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name ('notification.createGotify') and lists parameters without explaining what the tool actually does. It doesn't specify that this creates a Gotify notification configuration or what Gotify is, nor does it distinguish this from sibling notification tools like createDiscord or createSlack. The description fails to provide a clear verb+resource statement of purpose.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. With multiple sibling notification tools (createDiscord, createEmail, createSlack, etc.), the description provides no context about when Gotify notifications are appropriate, what prerequisites might exist, or how this differs from other notification methods. This leaves the agent with no usage context.

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

• dokploy_notification_createSlackD
  1.7/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond this. It doesn't explain what 'create' entails (e.g., whether it sends a test notification, stores configuration, or requires specific permissions), leaving gaps in understanding the tool's effects. However, it doesn't contradict the annotations, so no contradiction is flagged.

  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 concise but overly minimal. It front-loads the tool name and method, followed by a parameter list, but the parameter list is redundant with the schema and adds no value. While not verbose, it lacks essential explanatory content, making it inefficient in conveying useful information.

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

  Completeness1/5

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

  Given the complexity (10 parameters, no output schema, 0% schema coverage), the description is highly incomplete. It doesn't explain the tool's purpose in detail, provide usage context, clarify parameter meanings, or describe expected outcomes. With annotations covering basic hints but no rich behavioral details, the description fails to compensate for the gaps, making it inadequate for effective tool use.

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

  Parameters1/5

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

  The description lists parameters with types but provides no semantic meaning. With 0% schema description coverage and 10 required parameters, the description fails to explain what each boolean parameter controls (e.g., what 'appBuildError' or 'serverThreshold' mean in context) or how 'webhookUrl' and 'channel' should be formatted. This leaves parameters largely undocumented.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal additional context. It mentions '[notification] notification.createSlack (POST)' which indicates it creates a Slack notification, but this is already obvious from the name. It doesn't specify what kind of Slack notification or what triggers it, making the purpose vague rather than specific.

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

  Usage Guidelines1/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 sibling tools list includes other notification creation tools (e.g., createDiscord, createEmail), but the description provides no comparison or context for choosing Slack over other notification methods. This leaves the agent without any usage direction.

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

• dokploy_rollback_rollbackD
  1.7/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond what annotations provide. It doesn't explain what 'rollback' means operationally, whether it affects system state, what permissions are required, or what the expected outcome is. With annotations covering basic hints, the description fails to add meaningful behavioral insight.

  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 extremely concise—just one line with a parameter list—but this brevity comes at the cost of being under-specified rather than efficient. While it's structured with a clear parameter section, the core description '[rollback] rollback.rollback (POST)' is redundant and uninformative, making the conciseness feel inadequate rather than optimal.

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

  Completeness1/5

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

  Given the tool's likely complexity (performing a rollback operation), the absence of an output schema, 0% schema description coverage, and minimal annotations, the description is severely incomplete. It doesn't explain the tool's purpose, behavior, parameters, or outcomes, making it inadequate for an agent to understand or use this tool effectively in context.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description only lists 'rollbackId (string, required)' without explaining what a rollbackId is, how to obtain it, its format, or its significance. This fails to compensate for the complete lack of schema documentation, leaving the parameter's purpose and usage completely unclear.

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

  Purpose2/5

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

  The description states '[rollback] rollback.rollback (POST)' which is essentially a tautology of the tool name and title, providing no meaningful explanation of what the tool actually does. It doesn't specify what resource is being rolled back, what a rollback entails in this context, or how it differs from other rollback-related tools like 'dokploy_rollback_delete'.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, appropriate contexts, or what distinguishes this rollback operation from other deployment or management tools in the extensive sibling list.

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

• dokploy_application_saveBuildTypeD
  1.8/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond what annotations provide—no information about what 'saving' entails (e.g., whether it triggers builds, requires specific permissions, or has side effects). With annotations covering basic hints, the description fails to add meaningful behavioral insight.

  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 structured with a header and bulleted parameter list, which is organized but not front-loaded with purpose. It wastes space repeating obvious information (HTTP method) and listing parameters without context. While not verbose, it lacks efficiency in conveying essential information.

  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 9 parameters (7 required) with 0% schema coverage, no output schema, and annotations that only provide basic hints, the description is highly incomplete. It does not explain the tool's role in the application lifecycle, the meaning of parameters, expected outcomes, or error conditions, leaving significant gaps for a complex configuration tool.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning no parameters have descriptions in the schema. The description merely lists parameter names and types without explaining what they mean, how they interact with buildType, or their purpose (e.g., why dockerContextPath is required for all build types). This fails to compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description restates the tool name ('application.saveBuildType') and HTTP method without explaining what the tool actually does. It provides a parameter list but no functional description of saving or configuring build types for applications. This is essentially a tautology of the name/title.

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

  Usage Guidelines1/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. With many sibling tools like dokploy_application_create, dokploy_application_update, and dokploy_application_deploy, the description fails to explain when build type configuration should occur in the application lifecycle or what prerequisites might be needed.

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

• dokploy_application_saveEnvironmentD
  1.8/5.0
  Behavior2/5

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

  Annotations provide basic hints (non-readonly, non-destructive, non-idempotent, open-world), but the description adds almost no behavioral context. It doesn't explain what 'saveEnvironment' means operationally - whether this overwrites existing environment, merges with it, or creates new. No information about permissions needed, side effects, or what happens on success/failure. The description doesn't contradict annotations, but adds minimal value beyond them.

  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 technically concise - it's just a parameter list. However, this conciseness comes at the cost of being under-specified. The structure shows parameters but lacks any explanatory prose about the tool's function. While not verbose, it fails to provide necessary context that would help an agent understand and use the tool correctly.

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

  Completeness1/5

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

  This is a mutation tool (non-readonly) with 5 parameters, 0% schema description coverage, no output schema, and complex sibling context. The description is completely inadequate - it doesn't explain what the tool does, when to use it, what the parameters mean, or what behavior to expect. For a tool that likely modifies application environment configuration, this level of documentation is insufficient.

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

  Parameters2/5

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

  With 0% schema description coverage for 5 parameters, the description carries full burden. It merely lists parameter names and types without explaining what 'env', 'buildArgs', 'buildSecrets' contain, what format they should be in, or what 'createEnvFile' actually does. The 'any' type parameters especially need semantic clarification that isn't provided.

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

  Purpose2/5

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

  The description is essentially a tautology - it restates the tool name 'application.saveEnvironment' without explaining what 'saveEnvironment' actually does. It provides no verb or resource context beyond what's already in the name. While it lists parameters, it doesn't articulate the tool's purpose or what environment is being saved.

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

  Usage Guidelines1/5

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

  There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives, what prerequisites exist, or what context it operates in. With many sibling tools available (like various 'save' operations for different resources), this lack of guidance is particularly problematic.

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

• dokploy_application_startD
  1.8/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond what annotations provide—it doesn't explain what 'start' entails (e.g., launching containers, changing status), potential side effects, error conditions, or permissions required. With annotations covering basic hints, the description fails to add meaningful value.

  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 brief and front-loaded with the tool name, but includes redundant information (POST method) and a parameter list that doesn't add value. It's concise but under-specified, with sentences that don't earn their place by providing useful guidance.

  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 (a state-changing operation), lack of output schema, and minimal annotations, the description is inadequate. It doesn't explain what the tool does, when to use it, what parameters mean, or what to expect upon success/failure. This leaves significant gaps for an AI agent to understand and invoke the tool correctly.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description merely lists 'applicationId' as a required parameter without explaining what it is, where to find it, its format, or constraints. This adds no semantic information beyond the schema's type and requirement, failing to compensate for the lack of schema descriptions.

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

  Purpose2/5

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

  The description restates the tool name and title ('application.start') without adding meaningful context about what 'start' means operationally. It mentions 'POST' which is redundant with HTTP method annotations, and lists the parameter without explaining the action's effect. This is essentially tautological rather than clarifying purpose.

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

  Usage Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives like 'dokploy_application_stop' or 'dokploy_application_deploy'. The description lacks any context about prerequisites, expected state of the application, or typical scenarios for invocation.

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

• dokploy_mysql_updateD
  1.8/5.0
  Behavior3/5

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

  The description adds no behavioral information beyond what annotations provide. Annotations indicate this is a mutable (readOnlyHint: false), non-destructive (destructiveHint: false), idempotent (idempotentHint: true) operation with open-world semantics (openWorldHint: true). The description doesn't mention what gets updated, whether changes are immediate or require deployment, what permissions are needed, or any side effects. However, since annotations provide basic behavioral hints, the bar is lower, and the description doesn't contradict them.

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

  Conciseness2/5

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

  While technically concise (just two lines), the description is under-specified rather than efficiently informative. The first line '[mysql] mysql.update (POST)' wastes space on obvious information (the tool name and HTTP method), and the parameter list is a raw dump without organization or prioritization. The structure doesn't front-load important information about the tool's purpose or usage.

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

  Completeness1/5

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

  For a complex database update tool with 32 parameters, no output schema, and no annotations covering critical behavioral aspects (like whether updates require redeployment or affect running instances), the description is completely inadequate. It doesn't explain what happens after the update, what values are returned, whether the update is atomic, or how it interacts with other MySQL operations. The combination of high complexity and minimal description makes this tool difficult for an agent to use correctly.

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

  Parameters1/5

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

  With 32 parameters and 0% schema description coverage, the description provides only a bare parameter list without any semantic explanation. The schema documents types and constraints but not meaning. The description fails to explain what mysqlId refers to, what fields can be updated, how optional parameters interact, or the significance of swarm-related parameters. For a complex update operation with many parameters, this is severely inadequate.

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

  Purpose2/5

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

  The description only states '[mysql] mysql.update (POST)' followed by a parameter list, which essentially restates the tool name and HTTP method without explaining what the tool actually does. It doesn't specify what resource is being updated (a MySQL database instance/container) or what the update operation entails. This is tautological rather than providing meaningful purpose clarification.

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

  Usage Guidelines1/5

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

  The description provides zero guidance on when to use this tool versus alternatives. With many sibling tools for different database types (mariadb, mongo, postgres, redis) and various MySQL operations (create, delete, deploy, start, stop), there's no indication of when this update tool is appropriate versus creating a new instance or using other MySQL tools. No prerequisites, dependencies, or contextual usage information is provided.

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

• dokploy_notification_createDiscordD
  1.8/5.0
  Behavior3/5

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

  The annotations provide basic hints (not read-only, not destructive, not idempotent, open world), but the description adds no behavioral context beyond what's already in annotations. It doesn't explain what 'creates' means operationally, whether this requires specific permissions, what happens if a notification with the same name exists, or what the response looks like. With annotations covering the basic safety profile, the description adds minimal value but doesn't provide rich behavioral details.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently structured. It wastes space on a redundant header and a parameter list that adds no value beyond what's already in the schema. The structure doesn't front-load essential information about the tool's purpose, and the parameter list should have been omitted since it provides no additional context.

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

  Completeness1/5

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

  This is a creation tool with 10 required parameters, no output schema, and annotations that only provide basic hints. The description is completely inadequate for this context - it doesn't explain what the tool creates, what the parameters mean, what the expected response is, or how this differs from other notification tools. For a complex creation operation, this description provides almost no useful information.

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

  Parameters1/5

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

  The description lists parameter names and types but provides zero semantic meaning. With 10 required parameters and 0% schema description coverage, the description fails completely to explain what each parameter means (e.g., what 'appBuildError' controls, what 'decoration' does, what format 'webhookUrl' expects). The agent would have to guess the purpose of each boolean flag and string field based solely on their names.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal context. It states '[notification] notification.createDiscord (POST)' which just repeats the name and adds the HTTP method, but doesn't explain what the tool actually does. The parameter list that follows doesn't constitute a purpose statement. A proper description would explain that this creates a Discord notification configuration in Dokploy.

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

  Usage Guidelines1/5

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

  There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool versus the many other notification creation tools (createEmail, createSlack, createTeams, etc.) listed among the siblings. It provides no context about prerequisites, when this tool is appropriate, or what alternatives exist for different notification types.

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

• dokploy_notification_createPushoverD
  1.8/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description doesn't contradict these (it implies creation, which aligns with non-readOnly). However, it adds no behavioral context beyond what annotations already cover - no information about what gets created, authentication requirements (though apiToken/userKey are parameters), rate limits, or what happens on duplicate calls. With annotations covering basic safety, the description adds minimal value.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently structured. It wastes space on a basic parameter list that adds little value without explanations, and the first line '[notification] notification.createPushover (POST)' is redundant with the tool name. The information is poorly organized and doesn't front-load the most important details about the tool's purpose.

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

  Completeness1/5

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

  This is a creation tool with 13 parameters (3 required), 0% schema description coverage, no output schema, and no behavioral context in the description. The description fails to explain what the tool does, when to use it, what the parameters mean, or what to expect as a result. Given the complexity and complete lack of parameter documentation, this description is wholly inadequate for an agent to understand and use the tool correctly.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning none of the 13 parameters have descriptions in the schema. The description merely lists parameter names and types without explaining what they mean, their purpose, or how they interact. For example, it doesn't explain what 'appBuildError' triggers, what 'priority' values correspond to, or what 'retry' and 'expire' control. This leaves critical semantic gaps for an agent trying to use the tool correctly.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal context. It mentions 'notification.createPushover (POST)' which indicates it creates a Pushover notification, but doesn't explain what Pushover is, what kind of notification system this integrates with, or what the tool actually accomplishes beyond the obvious from the name. No differentiation from sibling notification tools is provided.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or relationship to other notification tools (like createDiscord, createSlack, etc.). An agent would have no idea when this specific notification type is appropriate.

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

• dokploy_postgres_deployD
  1.8/5.0
  Behavior2/5

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

  The annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond what's already in annotations. For a deployment tool, the description should explain what 'deploy' entails - whether it creates resources, triggers a process, or performs some other action. With annotations providing basic safety information but the description adding no deployment-specific context, this represents minimal value addition.

  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 extremely concise - just '[postgres] postgres.deploy (POST)' - which could be considered efficient. However, this brevity comes at the cost of being under-specified rather than truly concise. The structure with brackets and parentheses is somewhat organized but doesn't follow conventional description patterns that would be more helpful to an AI agent.

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

  Completeness1/5

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

  For a deployment tool with no output schema, 0% parameter documentation, and annotations that only provide basic safety hints, this description is completely inadequate. It doesn't explain what the tool does, what the parameter means, what happens during deployment, what the expected outcome is, or how this differs from related tools. The description fails to provide the contextual information needed for an agent to use this tool effectively.

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

  Parameters2/5

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

  With 0% schema description coverage for the single 'postgresId' parameter, the description carries full burden for explaining parameter meaning. The description provides no information about what 'postgresId' represents, where to obtain it, what format it should be in, or what it references. This leaves the parameter completely undocumented despite being required.

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

  Purpose2/5

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

  The description '[postgres] postgres.deploy (POST)' is essentially a tautology that restates the tool name and HTTP method. It doesn't specify what 'deploy' actually means in this context - whether it's initial deployment, redeployment, or some other operation. While it mentions 'postgres', it doesn't distinguish this tool from other PostgreSQL-related tools like 'dokploy_postgres_create' or 'dokploy_postgres_redeploy'.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple PostgreSQL-related tools in the sibling list (create, deploy, move, rebuild, reload, remove, start, stop, update), but the description offers no context about when this specific 'deploy' operation is appropriate versus those other operations.

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

• dokploy_postgres_updateD
  1.8/5.0
  Behavior3/5

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

  The annotations provide good behavioral information (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), but the description adds no additional context about what 'update' means operationally. It doesn't explain whether this updates a running PostgreSQL instance, requires specific permissions, has side effects, or what happens to unspecified parameters. The description doesn't contradict annotations but adds minimal value beyond them.

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

  Conciseness2/5

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

  While technically concise (just one line), the description is under-specified rather than efficiently informative. It wastes its limited space on redundant information ([postgres] and (POST)) instead of providing meaningful content. The structure doesn't front-load essential information about the tool's purpose or usage.

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

  Completeness1/5

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

  For a complex mutation tool with 31 parameters, no output schema, and significant behavioral implications, the description is completely inadequate. It provides no context about what gets updated, how the update affects the PostgreSQL instance, what permissions are required, what the response contains, or how to interpret the many optional parameters. The annotations help but don't compensate for the description's complete lack of operational guidance.

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

  Parameters1/5

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

  With 31 parameters and 0% schema description coverage, the description provides absolutely no information about parameter meanings, relationships, or usage. The schema documents types and constraints, but the description doesn't explain what 'postgresId' identifies, what fields can be updated, how optional parameters interact, or the purpose of complex swarm-related parameters. This leaves the agent with only raw schema information.

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

  Purpose2/5

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

  The description '[postgres] postgres.update (POST)' is essentially a tautology that restates the tool name and HTTP method without explaining what the tool actually does. It mentions 'postgres' and 'update' but doesn't specify what is being updated (PostgreSQL database instance configuration) or what the update entails. This provides minimal value beyond the tool name itself.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. With 31 sibling tools including other database update tools (like dokploy_mariadb_update, dokploy_mysql_update) and related Postgres tools (dokploy_postgres_create, dokploy_postgres_deploy), there's no indication of when this specific update tool is appropriate versus creating a new instance or using other database tools.

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

• dokploy_redis_moveD
  1.8/5.0
  Behavior2/5

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

  Annotations indicate this is a mutable operation (readOnlyHint: false) that is non-destructive and non-idempotent. The description adds no behavioral context beyond what annotations provide - it doesn't explain what 'move' actually does, whether it's a migration with downtime, what permissions are required, or what the expected outcome is. For a tool with 'move' in its name and no output schema, this is insufficient behavioral disclosure.

  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 brief and structured with a clear parameter list, but it's under-specified rather than concise. The '[redis] redis.move (POST)' header is redundant with the tool name, and the parameter listing without explanations doesn't add meaningful value. While not verbose, it fails to provide necessary information efficiently.

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

  Completeness1/5

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

  This is a mutation tool (readOnlyHint: false) with no output schema and 0% schema description coverage. The description fails to explain what the tool does, when to use it, what the parameters mean, what behavior to expect, or what the result will be. Given the complexity implied by 'move' operations and complete lack of structured documentation, this description is wholly inadequate.

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

  Parameters2/5

  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 only lists parameter names (redisId, targetEnvironmentId) without explaining what these IDs represent, where to find them, what format they should be in, or what the relationship is between source and target environments. The description adds minimal value beyond the bare parameter names already visible in the schema.

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

  Purpose2/5

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

  The description restates the tool name ('redis.move') and lists parameters without explaining what 'move' means in this context. It doesn't specify what resource is being moved (Redis instance, database, data?) or what 'move' entails (migration, relocation, reassignment?). This is essentially a tautology of the name with parameter listing.

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

  Usage Guidelines1/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 sibling tools list includes other Redis tools (create, delete, deploy, etc.) and other 'move' tools (application_move, mariadb_move, etc.), but the description provides no context about when this specific Redis move operation is appropriate versus creating new instances or using other Redis operations.

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

• dokploy_registry_updateD
  1.8/5.0
  Behavior2/5

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

  Annotations provide some behavioral hints (non-readOnly, non-destructive, idempotent, openWorld), but the description adds almost no context beyond what's already in annotations. It doesn't explain what 'update' entails (partial vs full updates), whether authentication is required, what happens to unspecified fields, or any side effects. The description doesn't contradict annotations, but fails to provide meaningful behavioral context for a mutation tool.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently structured. It wastes space on a redundant API endpoint notation ('[registry] registry.update (POST)') and a bare parameter list without grouping or prioritization. The information is poorly organized and doesn't front-load the most important details about the tool's purpose.

  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?

  For a mutation tool with 10 parameters, 0% schema coverage, no output schema, and only basic annotations, the description is severely inadequate. It doesn't explain what a 'registry' is in this context, what fields can be updated, what the expected response looks like, or any error conditions. The description fails to provide the necessary context for effective tool use.

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

  Parameters2/5

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

  With 0% schema description coverage and 10 parameters (1 required, 9 optional), the description merely lists parameter names without any semantic explanation. It doesn't clarify what 'registryId' identifies, what 'imagePrefix' accepts, what 'registryType: cloud' means, or how parameters relate to each other. The description fails to compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name ('registry.update') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being updated (a container registry configuration), what 'update' means in this context, or how it differs from sibling registry tools like 'dokploy_registry_create' or 'dokploy_registry_remove'.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an existing registry to update), when this should be used instead of creating a new registry, or any constraints on usage. With many sibling tools available, this lack of differentiation is problematic.

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

• dokploy_security_updateD
  1.8/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no behavioral context beyond what's in annotations - it doesn't explain what 'security.update' actually changes, whether it requires specific permissions, what happens to existing security settings, or what the response looks like. With annotations covering basic safety profile, the description adds minimal value.

  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 brief but not well-structured. It starts with '[security] security.update (POST)' which is redundant with name/title, then lists parameters without context. While concise, it's under-specified rather than efficiently informative.

  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?

  For a security update tool with 3 parameters (0% schema coverage), no output schema, and annotations that only cover basic safety hints, the description is inadequate. It doesn't explain what security aspect is being updated, what the parameters mean, what the operation changes, or what to expect as a result. The combination of poor parameter documentation and vague purpose makes this incomplete.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning none of the 3 parameters have descriptions in the schema. The description merely lists parameter names and types without explaining what securityId refers to, what username/password are for, or their relationship. This fails to compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description restates the name/title ('security.update') and lists parameters without explaining what the tool actually does. It doesn't specify what kind of security update this performs (e.g., updating credentials, permissions, or security settings) or what resource is being updated. This is closer to tautology than clear purpose definition.

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

  Usage Guidelines1/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 doesn't mention any prerequisites, context requirements, or when this specific security update operation is appropriate compared to other security-related tools (like dokploy_security_create or dokploy_security_delete).

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

• dokploy_settings_toggleDashboardD
  1.8/5.0
  Behavior2/5

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

  Annotations provide basic hints (not read-only, not destructive, not idempotent, open world), but the description adds no behavioral context beyond this. It doesn't explain what 'toggle' means in practice - whether this is a simple on/off switch, what permissions are required, whether changes are immediate or require restart, or what side effects might occur. For a settings mutation tool, this is insufficient behavioral disclosure.

  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 technically concise (two lines), but this conciseness comes at the cost of clarity. The structure shows the tool path and lists parameters, but it's not front-loaded with purpose. While not verbose, it's under-specified rather than efficiently informative.

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

  Completeness1/5

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

  For a settings mutation tool with 2 parameters, 0% schema description coverage, no output schema, and no annotations explaining behavior beyond basic hints, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what the parameters mean, what happens when invoked, or what to expect in return. This leaves the agent guessing about fundamental aspects of the tool.

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

  Parameters2/5

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

  The description lists parameters but provides no semantic meaning. With 0% schema description coverage and no output schema, the description fails to explain what 'enableDashboard' actually controls (enable what dashboard? where?), what 'serverId' refers to (which server's dashboard?), or whether both parameters are required together. The parameter listing adds minimal value beyond what the bare schema provides.

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

  Purpose2/5

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

  The description states '[settings] settings.toggleDashboard (POST)' which is tautological - it essentially repeats the tool name and adds HTTP method. It doesn't explain what 'toggleDashboard' actually does - whether it enables/disables a dashboard, what dashboard it refers to, or what the effect is. The description fails to provide a clear verb+resource statement of purpose.

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

  Usage Guidelines1/5

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

  There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives, what prerequisites might be needed, or what context would warrant its use. Given the many sibling tools in the settings category (like dokploy_settings_getWebServerSettings, dokploy_settings_readTraefikConfig, etc.), there's no guidance on when this specific toggle is appropriate.

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

• dokploy_sso_registerD
  1.8/5.0
  Behavior2/5

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

  The description provides no behavioral information beyond what's in the annotations. Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, but the description doesn't add any context about what 'register' actually does behaviorally, what gets created, authentication requirements, or any side effects. However, it doesn't contradict the annotations.

  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 technically concise but under-specified rather than efficiently informative. It wastes space on redundant information like '(POST)' while providing minimal useful content. The parameter list is presented but without meaningful context, making the structure functional but not helpful.

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

  Completeness1/5

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

  For a complex SSO registration tool with 7 parameters (including deeply nested OIDC and SAML configuration objects), 0% schema description coverage, no output schema, and no annotations providing behavioral context, this description is completely inadequate. It fails to explain what the tool does, when to use it, what parameters mean, or what to expect as a result.

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

  Parameters2/5

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

  With 0% schema description coverage and 7 parameters (including complex nested objects), the description provides only a basic parameter list without any semantic explanation. It doesn't explain what 'providerId', 'issuer', 'domains', or the configuration objects represent, what format they should be in, or how they relate to SSO registration. The description fails to compensate for the complete lack of schema descriptions.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal context. It states '[sso] sso.register (POST)' which repeats the name and adds HTTP method, but doesn't explain what 'register' means in the SSO context. No specific verb+resource combination or differentiation from sibling tools is provided.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this should be used versus other SSO tools in the sibling list (like dokploy_sso_update, dokploy_sso_deleteProvider, etc.), or any context about appropriate use cases.

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

• dokploy_sso_updateD
  1.8/5.0
  Behavior3/5

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

  Annotations indicate the tool is not read-only, not destructive, idempotent, and open-world, which the description does not contradict. However, it adds no behavioral context beyond these hints, such as explaining what 'update' entails (e.g., overwriting settings), authentication requirements, or rate limits, missing opportunities to enhance transparency.

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

  Conciseness2/5

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

  The description is under-specified rather than concise; it wastes space on a redundant header and a bare parameter list without explanatory context. It lacks front-loaded purpose and is structured poorly, with every sentence failing to add value beyond what the schema already provides in terms of parameter existence.

  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 (7 parameters with nested objects), no output schema, and 0% schema description coverage, the description is incomplete. It does not explain the update operation's scope, expected outcomes, error conditions, or how it fits into the SSO workflow, leaving significant gaps for an agent to understand and use the tool effectively.

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

  Parameters2/5

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

  With 0% schema description coverage and 7 parameters (3 required, 4 optional), the description only lists parameter names and types without explaining their meanings, relationships (e.g., oidcConfig vs. samlConfig), or constraints. This fails to compensate for the schema's lack of descriptions, leaving parameters largely undocumented.

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

  Purpose1/5

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

  The description is a tautology that merely restates the tool name 'dokploy_sso_update' as '[sso] sso.update (POST)' and provides a parameter list without any explanation of what the tool does. It fails to specify the action (e.g., update SSO provider configuration) or the resource involved, offering no meaningful purpose statement.

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

  Usage Guidelines1/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 lacks context about prerequisites, such as needing an existing SSO provider to update, and does not reference sibling tools like 'dokploy_sso_one' or 'dokploy_sso_listProviders' for related operations, leaving usage entirely ambiguous.

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

• dokploy_application_cancelDeploymentD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=true and destructiveHint=false, suggesting a safe operation, but the description implies a mutation ('cancelDeployment'), which could be contradictory. However, it doesn't explicitly state 'creates' or 'deletes', so it's not a direct contradiction. The description adds no behavioral context beyond annotations, such as what happens to the deployment (e.g., is it stopped immediately, queued for cancellation, etc.), error conditions, or side effects.

  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 brief and front-loaded with the tool name and method, but it includes redundant formatting (brackets, parentheses) and a parameter list that adds little value. It's not verbose, but the structure is minimal and could be more informative without sacrificing conciseness.

  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 a deployment cancellation operation, the description is inadequate. No output schema exists, and annotations provide limited behavioral hints. The description fails to explain what the tool does, when to use it, or what to expect in return, leaving significant gaps for an AI agent to understand and invoke it correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists 'applicationId' as a required parameter but adds no semantic meaning (e.g., what format it expects, where to find it, or what it represents). This minimal information doesn't compensate for the lack of schema documentation.

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

  Purpose2/5

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

  The description restates the tool name ('application.cancelDeployment') and HTTP method ('POST'), which is tautological. It doesn't explain what 'cancelDeployment' means in this context (e.g., stopping an in-progress deployment, queuing a cancellation, etc.). While it mentions the resource ('application'), the action is unclear 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 Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives. Sibling tools include 'dokploy_application_killBuild', 'dokploy_application_stop', and 'dokploy_application_clearDeployments', which might serve similar or overlapping purposes, but the description doesn't differentiate this tool from them or specify prerequisites like deployment status.

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

• dokploy_application_clearDeploymentsD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond this, such as what 'clear' entails (e.g., deletion, archival, reset), potential side effects, or error conditions. For a tool with 'clear' in its name, the lack of clarification on impact is a significant gap, though it doesn't contradict annotations.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) and a parameter list that adds little value. While not verbose, it wastes space on restating obvious information instead of providing useful context, reducing its effectiveness.

  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 name suggests a mutation ('clear'), annotations provide basic safety hints but no output schema, and schema coverage is 0%, the description is incomplete. It lacks details on what the tool does, when to use it, parameter meaning, and expected outcomes. For a tool with potential operational impact, this is inadequate.

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

  Parameters2/5

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

  Schema description coverage is 0%, with one parameter 'applicationId' documented only as a required string. The description lists the parameter but adds no semantics—it doesn't explain what an 'applicationId' is, how to obtain it, or its format. This fails to compensate for the low schema coverage, leaving the parameter's meaning unclear.

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

  Purpose2/5

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

  The description restates the tool name and title ('application.clearDeployments') without explaining what 'clearDeployments' means. It doesn't specify what resource is being cleared (e.g., deployment history, queued deployments, or active deployments) or what the outcome is. Compared to siblings like 'dokploy_application_cancelDeployment' or 'dokploy_application_cleanQueues', it lacks differentiation, making the purpose vague.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after failed deployments), or exclusions. With many sibling tools like 'cancelDeployment' and 'cleanQueues', the absence of usage guidelines is misleading, as an agent cannot infer the correct scenario for invocation.

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

• dokploy_application_refreshTokenD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond that. It doesn't explain what 'refreshToken' entails (e.g., whether it returns a new token, affects existing sessions, or requires specific permissions). Given the lack of annotations on side effects or auth needs, the description fails to compensate, leaving key behaviors unclear.

  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 brief and structured with a parameter list, but it's under-specified rather than concise. The first line repeats obvious information (name and HTTP method), and the parameter listing is redundant with the schema. While not verbose, it wastes space on unhelpful details instead of earning its place with useful content.

  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?

  For a tool with one parameter, no output schema, and annotations covering basic hints, the description is incomplete. It doesn't explain the action's outcome (e.g., what the refreshed token is used for), error conditions, or integration with sibling tools. Given the complexity implied by 'refreshToken' in a deployment context, more context is needed for effective use.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only lists 'applicationId' as a required string without explaining its purpose (e.g., identifier of the application whose token needs refreshing). It doesn't clarify format, source, or constraints beyond the schema's minLength. With low coverage, the description should add meaning but provides minimal semantic value.

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

  Purpose2/5

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

  The description restates the tool name and title ('application.refreshToken') without explaining what 'refreshToken' means in this context. It mentions the HTTP method (POST) and lists the parameter, but doesn't specify what the tool actually does (e.g., generates a new token, invalidates old ones, or updates authentication credentials). This is a tautology that provides minimal additional insight 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 Guidelines1/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 doesn't mention any prerequisites, related tools (like 'dokploy_application_one' for retrieving application details), or scenarios where token refreshing is necessary (e.g., after expiration). Without this, an agent cannot determine appropriate usage contexts.

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

• dokploy_application_saveGiteaProviderD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond what's already in annotations. It doesn't explain what 'saving' entails (e.g., creates new provider, updates existing, requires specific permissions), doesn't mention side effects, and provides no information about response format or error conditions. With annotations covering basic safety hints, the description adds minimal value but fails to provide meaningful behavioral transparency.

  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 concise with a clear structure: tool name with HTTP method followed by a parameter list. However, it's under-specified rather than efficiently concise - it lacks essential explanatory content that would help an agent understand the tool's purpose and usage. The parameter list formatting is clear but doesn't add value beyond what's already in the schema.

  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 (8 parameters, mutation operation, no output schema), the description is severely incomplete. It doesn't explain what the tool does, when to use it, what the parameters mean, what behavior to expect, or what the response contains. With annotations providing only basic safety hints and no output schema, the description fails to provide the contextual information needed for effective tool selection and invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The description lists parameter names and types but provides no semantic meaning for any parameters. It doesn't explain what 'giteaId' represents, what 'watchPaths' are for, or how parameters relate to each other. For a tool with 8 parameters and zero schema coverage, this minimal parameter listing is insufficient to compensate for the documentation gap.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal additional context. It states 'application.saveGiteaProvider (POST)' which repeats the name and adds the HTTP method, but doesn't explain what saving a Gitea provider actually does or what resource it affects. While it mentions 'application' context, it lacks a specific verb-resource combination that clarifies the tool's function beyond its name.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling tools with similar naming patterns (e.g., saveBitbucketProvider, saveGithubProvider, saveGitlabProvider, saveGitProvider), but the description offers no differentiation or context about when this specific Gitea provider tool should be selected over those other provider tools or other application-related tools.

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

• dokploy_application_saveGitlabProviderD
  1.9/5.0
  Behavior3/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description doesn't contradict these but adds minimal behavioral context—it implies a POST request for saving configuration, which aligns with the annotations. However, it lacks details on side effects, error conditions, or authentication needs beyond what annotations provide.

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

  Conciseness2/5

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

  The description is under-specified rather than concise—it wastes space on a redundant tool name and a bare parameter list without meaningful explanations. It lacks front-loaded purpose and structured guidance, making it inefficient for an AI agent to parse and use effectively.

  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 (10 parameters, no output schema, 0% schema coverage), the description is incomplete. It doesn't explain what the tool does, when to use it, parameter meanings, or expected outcomes. Annotations provide some behavioral hints, but the description fails to add necessary context for a configuration-saving operation in a system with many sibling tools.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning no parameters are documented in the schema. The description merely lists parameter names and types without explaining their purpose (e.g., what gitlabId or gitlabPathNamespace represent). For a tool with 10 parameters (8 required), this leaves critical semantics undefined, failing to compensate for the schema gap.

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

  Purpose2/5

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

  The description restates the tool name ('application.saveGitlabProvider') and lists parameters without explaining what the tool actually does. It lacks a clear verb+resource statement like 'saves GitLab provider configuration for an application' and doesn't distinguish it from sibling tools like dokploy_application_saveGithubProvider or dokploy_application_saveBitbucketProvider.

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

  Usage Guidelines1/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 doesn't mention prerequisites (e.g., needing an existing application), context for GitLab integration, or when to choose this over other Git provider tools like saveGithubProvider or saveBitbucketProvider from the sibling list.

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

• dokploy_compose_deployTemplateD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond what annotations provide. It fails to explain what 'deployTemplate' entails (e.g., whether it triggers deployments, modifies resources, or has side effects), which is critical given the lack of output schema and the tool's likely mutation role.

  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 concise but under-specified, consisting of a tautological title line and a bare parameter list. While not verbose, it lacks meaningful content, making it inefficient in conveying necessary information rather than being appropriately succinct.

  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 likely complexity (deploying templates in a compose context), the absence of an output schema, and minimal annotations, the description is highly incomplete. It does not explain the operation's outcome, error conditions, or interaction with the system, leaving significant gaps for an agent to understand and use the tool effectively.

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

  Parameters2/5

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

  With 0% schema description coverage and 4 parameters (2 required), the description merely lists parameter names without any semantic explanation. It does not clarify what 'environmentId', 'serverId', 'id', or 'baseUrl' represent, their formats, or how they influence the deployment, failing to compensate for the schema's lack of descriptions.

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

  Purpose2/5

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

  The description is tautological, essentially restating the tool name as '[compose] compose.deployTemplate (POST)' without explaining what 'deployTemplate' means. It provides no verb+resource combination or functional purpose, making it unclear what the tool actually does beyond its name.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description offers no context, prerequisites, or distinctions from sibling tools like 'dokploy_compose_deploy' or 'dokploy_compose_templates', leaving the agent with no usage direction.

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

• dokploy_compose_fetchSourceTypeD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context. It doesn't explain what 'fetchSourceType' returns, whether it has side effects, or what authentication/rate limits apply. For a POST operation with openWorldHint=true, the description should clarify what 'source type' means and how the fetch works.

  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 brief but inefficiently structured—it wastes space on obvious details like '(POST)' and a redundant parameter list. The first line could directly state the tool's purpose. However, it's not overly verbose, so it avoids a lower score.

  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 implied by 'fetchSourceType' (likely retrieving metadata about a compose resource), no output schema, and minimal annotations, the description is inadequate. It doesn't explain what a 'source type' is, what values might be returned, or how this integrates with other compose tools. For a tool with potential nuance, more context is needed.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only repeats the parameter name ('composeId') without explaining what a composeId is, where to find it, or its format. It doesn't add meaning beyond the schema's basic type/requirement constraints. With 1 parameter and no schema descriptions, the description should compensate by clarifying the parameter's purpose.

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

  Purpose2/5

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

  The description restates the tool name and method (POST) without explaining what 'fetchSourceType' means or what resource it operates on. It mentions 'compose' but doesn't specify if this is about Docker Compose files, templates, or something else. Compared to sibling tools like 'dokploy_compose_create' or 'dokploy_compose_deploy', it's unclear what specific action this performs.

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

  Usage Guidelines1/5

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

  No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or what problem this tool solves. With many compose-related siblings (e.g., 'dokploy_compose_getTags', 'dokploy_compose_loadServices'), there's no indication of how this tool differs or when it's appropriate.

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

• dokploy_compose_importD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation, but the description adds no behavioral context. It doesn't explain what 'import' entails (e.g., whether it creates or updates resources, potential side effects, or error conditions). With annotations covering basic hints, the description adds minimal value beyond them.

  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 brief and structured with a header and parameter list, but it's under-specified rather than concise. It wastes space on formatting (brackets, dashes) without delivering meaningful content. While not verbose, it lacks substance, making it inefficient in conveying necessary information.

  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 has 2 parameters with 0% schema coverage, no output schema, and annotations that only provide basic hints, the description is incomplete. It doesn't explain the tool's function, parameter meanings, expected outcomes, or error handling. For a tool likely involving data import operations, this leaves significant gaps in understanding.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameter names and types but doesn't explain their semantics (e.g., what 'base64' represents, what 'composeId' is used for, or format requirements). It fails to compensate for the lack of schema descriptions, leaving parameters largely undocumented.

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

  Purpose2/5

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

  The description merely restates the tool name and title ('compose.import') without explaining what it does. It lists parameters but doesn't specify the action (e.g., importing a Docker Compose configuration from base64 data). This is a tautology that fails to clarify the tool's purpose beyond its name.

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

  Usage Guidelines1/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. Sibling tools include many compose-related tools (e.g., dokploy_compose_create, dokploy_compose_deploy), but the description provides no context for selection. This leaves the agent without usage direction.

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

• dokploy_compose_moveD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readonly, non-destructive, non-idempotent operation with open-world semantics. The description adds nothing beyond this - no information about what 'move' entails operationally, whether it's a migration between environments, what happens to the original compose, authentication requirements, rate limits, or expected side effects. With annotations providing basic safety hints, the description fails to add meaningful behavioral context.

  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 technically concise with just the tool signature and parameter list, but this conciseness comes at the cost of being under-specified. While not verbose, it fails to provide essential information that would help an AI agent understand and use the tool effectively.

  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 this is a mutation tool (non-readonly) with 2 required parameters, 0% schema description coverage, no output schema, and complex sibling tools, the description is severely inadequate. It doesn't explain what the tool does, when to use it, what the parameters mean, or what behavior to expect - leaving critical gaps for agent understanding.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description merely lists parameter names and types without explaining what 'composeId' and 'targetEnvironmentId' represent, their format, or how they relate to the move operation. This minimal parameter listing doesn't compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description restates the tool name as '[compose] compose.move (POST)' which is essentially a tautology, providing no meaningful explanation of what the tool actually does. It doesn't specify what resource 'compose' refers to or what 'move' operation performs. The parameter list is included but doesn't clarify purpose.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparison to sibling tools like 'dokploy_application_move' or other 'move' operations for different resource types (mariadb_move, mongo_move, etc.).

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

• dokploy_compose_refreshTokenD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, which aligns with the non-read-only hint, but doesn't provide additional behavioral context (e.g., what 'refreshToken' entails, side effects, authentication needs, or rate limits). With annotations covering basic traits, the description adds minimal value beyond confirming the HTTP method.

  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 brief and front-loaded with the tool name and HTTP method, but it includes a redundant parameter list that doesn't add value beyond the schema. It could be more concise by omitting the parameter listing or integrating it with meaningful explanations.

  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 has no output schema and low schema description coverage, the description is incomplete. It lacks details on what the tool does, when to use it, parameter meanings, and expected outcomes. For a tool with one parameter and no output schema, more context is needed to guide effective use.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists 'composeId' as a required string parameter but doesn't explain what a composeId is, where to find it, or its format. This adds minimal semantics beyond the schema's structural information.

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

  Purpose2/5

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

  The description restates the tool name and title ('compose.refreshToken') without explaining what 'refreshToken' means in this context. It mentions 'POST' and lists parameters, but doesn't specify what the tool actually does (e.g., generates a new token for a compose resource, invalidates old tokens, etc.). This is closer to tautology than clear purpose.

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

  Usage Guidelines1/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. Sibling tools include 'dokploy_application_refreshToken' and other compose-related tools, but the description doesn't differentiate this tool from those or provide any context for its appropriate use.

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

• dokploy_compose_stopD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a mutation tool (readOnlyHint: false) but not destructive or idempotent. The description adds no behavioral context beyond what annotations provide - no information about what 'stop' actually does (graceful shutdown, container termination, service state), whether it requires specific permissions, what happens to dependent resources, or what the response looks like. With annotations covering basic safety profile but no output schema, the description should provide more operational context.

  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 technically concise (two lines) but wastes space on redundant formatting ('[compose] compose.stop (POST)') that adds no value. The parameter listing is structured but incomplete. While brief, it's not effectively front-loaded with useful information.

  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?

  For a mutation tool that stops a compose deployment with no output schema and 0% schema description coverage, the description is severely inadequate. It doesn't explain what 'stop' means operationally, what state the compose enters, how to verify success, or error conditions. Given the complexity implied by sibling tools (deploy, start, redeploy), this leaves critical gaps for agent understanding.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description only lists 'composeId' as a required string parameter without explaining what a composeId is, how to obtain it, format requirements, or what it identifies. This leaves the single parameter completely undocumented in practice.

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

  Purpose2/5

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

  The description restates the tool name ('compose.stop') without adding meaningful context about what 'stop' means in this system. It doesn't specify what resource is being stopped (a Docker Compose application/stack) or what the effect is. The description is essentially a tautology of the tool name with parameter formatting.

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

  Usage Guidelines1/5

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

  No guidance is provided about when to use this tool versus alternatives like 'dokploy_compose_start' or 'dokploy_application_stop'. The description doesn't mention prerequisites, dependencies, or appropriate contexts for stopping a compose deployment.

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

• dokploy_domain_createD
  1.9/5.0
  Behavior3/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. However, the description adds no behavioral context beyond what annotations provide—it doesn't explain what 'create' entails (e.g., whether it provisions resources, requires specific permissions, or has side effects like DNS propagation), missing opportunities to clarify the tool's behavior for the agent.

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

  Conciseness2/5

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

  While the description is brief, it's under-specified rather than concise—it wastes space on a redundant header ('[domain] domain.create (POST)') and a poorly formatted parameter list that adds no value. The structure is not front-loaded with useful information, making it inefficient and unhelpful for quick comprehension.

  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 (13 parameters, no output schema, and annotations that only cover basic hints), the description is highly incomplete. It doesn't address what the tool creates, how parameters relate to domain configuration, what the expected outcome is, or any prerequisites, failing to provide the context needed for effective use in a deployment environment.

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

  Parameters1/5

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

  With 13 parameters and 0% schema description coverage, the description fails to add any meaningful semantics beyond listing parameter names and basic types. It doesn't explain what parameters like 'host', 'path', or 'certificateType' mean in context, how they interact, or what values are appropriate, leaving the agent with insufficient guidance for proper tool invocation.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name 'dokploy_domain_create' as '[domain] domain.create (POST)', providing no meaningful explanation of what the tool actually does. It doesn't specify what resource is being created (e.g., a domain configuration, DNS record, or routing rule) or for what purpose, making it vague and unhelpful for understanding the tool's function.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'dokploy_domain_update', 'dokploy_domain_delete', 'dokploy_domain_generateDomain', and 'dokploy_domain_validateDomain', there is no indication of how this create operation differs from or relates to those other domain-related tools, leaving the agent with no context for selection.

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

• dokploy_environment_createD
  1.9/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds no behavioral context beyond what's in the annotations. For a creation tool, it doesn't mention what happens on duplicate names, whether there are permission requirements, rate limits, or what the response contains. With annotations covering basic safety, the description adds minimal value.

  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 concise with no wasted words, but it's under-specified rather than efficiently informative. The structure shows the HTTP method and lists parameters, but the information is too sparse. It's front-loaded with the tool signature but lacks substantive content.

  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?

  For a creation tool with 3 parameters (2 required), 0% schema description coverage, no output schema, and annotations that only cover basic safety hints, the description is inadequate. It doesn't explain what an environment is, what happens after creation, error conditions, or relationships to other entities. The context signals indicate significant complexity that the description doesn't address.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types but adds no semantic meaning - it doesn't explain what 'name' represents, what format 'projectId' should be in, or what 'description' is used for. This provides basic structure but insufficient context for effective use.

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

  Purpose2/5

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

  The description states '[environment] environment.create (POST)' which is a tautology that restates the tool name and adds the HTTP method. It doesn't specify what an 'environment' is in this context or what 'create' actually does. The parameter list provides some hints but doesn't constitute a clear purpose statement.

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

  Usage Guidelines1/5

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

  There are no guidelines about when to use this tool versus alternatives. The sibling tools include 'dokploy_environment_byProjectId', 'dokploy_environment_duplicate', 'dokploy_environment_one', 'dokploy_environment_remove', 'dokploy_environment_search', and 'dokploy_environment_update', but the description provides no differentiation or context about when this create operation is appropriate versus those other environment operations.

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

• dokploy_gitlab_testConnectionD
  1.9/5.0
  Behavior2/5

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

  Annotations provide basic hints (non-readOnly, non-destructive, non-idempotent, openWorld), but the description adds almost no behavioral context. It mentions 'POST' which aligns with non-readOnly, but doesn't describe what the test actually does (e.g., makes an API call to GitLab, validates credentials, returns success/failure status), what side effects might occur, or what authentication/rate limits apply. For a connection testing tool with no output schema, the description should explain what constitutes a successful test and what gets returned.

  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 concise but under-specified rather than efficiently informative. The first line '[gitlab] gitlab.testConnection (POST)' is front-loaded but lacks substance. The parameter listing adds structure but without meaningful explanations. While there's no wasted text, the description fails to provide essential information that would help an agent use the tool correctly.

  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 this is a connection testing tool with 2 parameters (0% schema coverage), no output schema, and annotations that only cover basic hints, the description is incomplete. It doesn't explain what a connection test entails, what success/failure looks like, what the gitlabId refers to, or when groupName is needed. For a tool that likely makes external API calls and returns status information, the description should provide more context about the operation's purpose and expected outcomes.

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

  Parameters2/5

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

  With 0% schema description coverage for both parameters, the description provides minimal parameter semantics. It lists parameter names (gitlabId, groupName) but doesn't explain what they represent (e.g., gitlabId is likely a provider ID from the system, groupName might be a GitLab group to test access to). The description doesn't clarify format expectations, examples, or how these parameters affect the connection test. For a tool with undocumented parameters, this is inadequate compensation.

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

  Purpose2/5

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

  The description states '[gitlab] gitlab.testConnection (POST)' which is essentially a tautology - it restates the tool name and HTTP method without explaining what 'testConnection' actually does. It doesn't specify what resource is being tested (GitLab provider configuration, credentials, network connectivity) or what constitutes a successful test. The sibling tools include other testConnection tools (bitbucket, gitea, github, destination, registry, notification types), but this description doesn't distinguish this GitLab-specific version from them.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing GitLab provider configuration), what problem it solves (verifying connectivity before deployment), or when not to use it. With multiple testConnection tools in the sibling list, there's no differentiation guidance for when to choose this GitLab-specific test over others.

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

• dokploy_mariadb_moveD
  1.9/5.0
  Behavior2/5

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

  Annotations provide basic hints (not read-only, not destructive, not idempotent, open-world), but the description adds no behavioral context beyond what's in annotations. For a 'move' operation, critical details are missing: whether this causes downtime, what happens to data, whether it's reversible, what permissions are needed, or what the response looks like. With annotations covering only basic safety hints, the description fails to add meaningful behavioral transparency.

  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 brief and structured with a parameter list, but it's under-specified rather than concise. The first line '[mariadb] mariadb.move (POST)' adds little value beyond the name/title. While not verbose, the description fails to communicate essential information efficiently.

  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 this is a mutation tool (moving database instances) with no output schema, 0% schema description coverage, and annotations that only provide basic hints, the description is severely incomplete. It doesn't explain what 'move' entails operationally, what the expected outcome is, potential side effects, or error conditions. For a tool that likely involves significant infrastructure changes, this is inadequate.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description merely lists parameter names and types without explaining what 'mariadbId' or 'targetEnvironmentId' represent, what format they should be in, or where to find valid values. This minimal information doesn't compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description restates the tool name and title ('mariadb.move') without explaining what 'move' means in this context. It lists parameters but doesn't state the actual purpose - whether it moves a MariaDB instance between environments, servers, or something else. This is essentially a tautology of the name/title.

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

  Usage Guidelines1/5

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

  No guidance is provided about when to use this tool versus alternatives. There are sibling tools like 'dokploy_mariadb_create', 'dokploy_mariadb_update', and other database move tools (e.g., 'dokploy_mysql_move', 'dokploy_mongo_move'), but the description offers no context about when moving is appropriate versus creating new instances or using other operations.

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

• dokploy_mariadb_reloadD
  1.9/5.0
  Behavior2/5

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

  Annotations provide some behavioral context (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), but the description adds almost nothing beyond this. It doesn't explain what 'reload' actually does behaviorally - whether it causes downtime, affects connected applications, has side effects, or what the expected outcome is. For a state-changing operation (readOnlyHint=false), the description should provide more context about the nature of the change, but it merely repeats the tool name.

  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 technically concise (three lines including the parameter list), but this conciseness comes at the cost of being under-specified. The structure is basic with a tool reference and parameter listing, but it lacks meaningful content. While not verbose, it fails to provide the necessary information that would justify its brevity in a helpful way.

  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 that this is a state-changing operation (readOnlyHint=false) with no output schema and 0% parameter documentation coverage, the description is severely incomplete. It doesn't explain what the tool does, when to use it, what parameters mean, what behavior to expect, or what the result will be. For a tool that presumably performs some kind of reload/restart operation on a MariaDB instance, this level of documentation is inadequate for safe and effective use by an AI agent.

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

  Parameters2/5

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

  With 0% schema description coverage for both parameters (mariadbId and appName), the description carries the full burden of explaining parameter meaning. However, it only lists the parameter names without any semantic explanation. The agent doesn't know what mariadbId refers to (database instance ID, container ID, configuration ID?), what format it should have, or what appName represents (application name, service name, project name?). The description fails to compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name ('mariadb.reload') and HTTP method (POST), providing no meaningful explanation of what the tool does. It doesn't specify what 'reload' means in this context (e.g., reload configuration, restart service, refresh connections) or what resource it acts upon beyond the generic 'mariadb' reference. While it distinguishes from some siblings by mentioning 'mariadb', it doesn't clearly differentiate from other mariadb tools like 'dokploy_mariadb_rebuild' or 'dokploy_mariadb_restart'.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or what problem this tool solves. With multiple sibling tools for mariadb management (changeStatus, rebuild, start, stop, etc.), the agent has no information about when a 'reload' operation is appropriate versus other state-changing operations.

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

• dokploy_mongo_saveExternalPortD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint. The description adds no behavioral context beyond what annotations provide. It doesn't explain what 'save' entails (e.g., whether it updates configuration, persists changes, or requires specific permissions), doesn't mention side effects, and provides no information about error conditions or response format. With annotations covering basic safety hints, the description adds minimal value.

  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 brief and front-loaded with the tool name and HTTP method, but it wastes space by repeating information already in the name/title. The parameter listing adds minimal value without explanations. While not verbose, it's under-specified rather than efficiently concise.

  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?

  For a mutation tool (non-readOnly) with 2 parameters, 0% schema description coverage, no output schema, and no sibling differentiation, the description is inadequate. It doesn't explain the operation's purpose, parameter meanings, expected outcomes, or error handling. Given the complexity implied by the tool name and annotations, the description leaves too many gaps for effective use.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides only type information without semantic meaning. The description lists parameter names but adds no explanation of what 'mongoId' refers to (e.g., MongoDB instance identifier) or what 'externalPort' represents (e.g., port number for external access, null for disabling). It doesn't specify format constraints, valid ranges, or examples. The description fails to compensate for the lack of schema descriptions.

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

  Purpose2/5

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

  The description restates the tool name ('mongo.saveExternalPort') and HTTP method ('POST') without explaining what the tool actually does. It doesn't specify what resource is being modified or what 'saveExternalPort' means in context. While it mentions 'mongo' as a category, it doesn't distinguish this from sibling tools like 'dokploy_mariadb_saveExternalPort' or 'dokploy_mysql_saveExternalPort' beyond the database type.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or relationships with other tools (e.g., whether this should be used during deployment, configuration, or maintenance). There's no indication of when this operation is needed or what alternatives might exist.

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

• dokploy_mongo_startD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond what's in annotations. It doesn't explain what 'start' entails (e.g., whether it requires specific permissions, what happens if the MongoDB is already running, or any side effects). With annotations covering basic hints, the description adds minimal value.

  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 brief and front-loaded with the tool name and method, but it's under-specified rather than concise. The parameter listing is redundant with the schema and doesn't add useful information, making the structure inefficient.

  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 (a state-changing operation with no output schema), the description is incomplete. It lacks details on prerequisites, expected outcomes, error conditions, and how it differs from sibling tools. Annotations provide some hints, but the description fails to add necessary context for effective use.

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

  Parameters2/5

  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, but it only lists 'mongoId' as a required string without explaining its meaning (e.g., what a MongoDB ID is, where to find it, or format examples). This adds little semantic value beyond the schema's type and requirement.

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

  Purpose2/5

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

  The description restates the tool name and title ('mongo.start') without providing a clear, specific purpose. It mentions 'POST' and lists parameters, but doesn't explain what 'start' means in this context (e.g., starting a MongoDB service/instance). This is a tautology that adds little beyond the name/title.

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

  Usage Guidelines1/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. Sibling tools include 'dokploy_mongo_stop', 'dokploy_mongo_changeStatus', and other database start tools (e.g., 'dokploy_mariadb_start'), but the description doesn't mention any of these or provide context for selection.

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

• dokploy_mounts_createD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond this, such as what 'create' entails (e.g., whether it modifies existing mounts, requires specific permissions, or has side effects). With annotations covering basic hints, the description fails to add meaningful behavioral insights.

  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 brief and front-loaded with the tool name, but it's under-specified rather than concise. The parameter list is structured but lacks explanatory value, making it inefficient. It avoids verbosity but fails to convey necessary information, so it's not optimally concise.

  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 (8 parameters, 0% schema coverage, no output schema, non-readOnly operation), the description is inadequate. It doesn't explain the tool's purpose, usage, or parameter meanings, leaving the agent with insufficient context to invoke it correctly. Annotations provide some hints, but the description adds little to compensate for the missing details.

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

  Parameters2/5

  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 lists parameters with minimal details (e.g., 'type (enum: bind, volume, file, required)'), but this adds little semantic value beyond the schema. It doesn't explain what each parameter means, their relationships (e.g., 'hostPath' for 'bind' type), or usage examples, leaving significant gaps.

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

  Purpose2/5

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

  The description essentially restates the tool name 'mounts.create' with '(POST)' and lists parameters, which is tautological. It doesn't clearly state what the tool does (e.g., create a mount for a service in Dokploy). While it mentions 'mounts.create', this is just the name/title restated without explaining the action or resource.

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

  Usage Guidelines1/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. It doesn't mention sibling tools like 'dokploy_mounts_update' or 'dokploy_mounts_remove', nor does it provide context on prerequisites or typical use cases (e.g., when setting up a service).

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

• dokploy_mysql_createD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint=true. The description adds no behavioral context beyond what annotations already provide. It doesn't explain what 'creates' actually means in practice (e.g., whether this provisions a new database instance, deploys a container, or creates configuration), what permissions are required, whether there are rate limits, or what happens on failure. For a creation tool with significant implications, this lack of behavioral disclosure is problematic.

  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 technically concise but structurally poor. It wastes the first line on redundant technical details ('[mysql] mysql.create (POST)') that don't add functional understanding. The parameter listing is organized but presented without meaningful grouping or prioritization. While not verbose, the structure doesn't effectively communicate the tool's purpose or usage.

  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?

  For a complex creation tool with 10 parameters, no output schema, and annotations that only cover basic hints, the description is severely incomplete. It doesn't explain what gets created, what the expected outcome is, potential side effects, error conditions, or relationships between parameters. The combination of high parameter count, zero schema descriptions, and minimal descriptive content makes this inadequate for safe and effective tool invocation.

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

  Parameters2/5

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

  With 0% schema description coverage and 10 parameters (5 required), the description carries full burden for explaining parameter meanings. While it lists parameter names and basic types, it provides no semantic context about what each parameter represents (e.g., 'environmentId' - what environment? 'databaseName' - naming constraints? 'dockerImage' - what images are valid?). The description fails to compensate for the complete lack of schema descriptions, leaving most parameters ambiguous.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name ('mysql.create') without explaining what it actually does. It lists parameters but doesn't state the action being performed (e.g., 'Creates a MySQL database instance' or 'Deploys a MySQL container'). While it mentions 'POST', this is technical implementation detail, not functional purpose. The description fails to distinguish this from sibling MySQL tools like 'dokploy_mysql_deploy' or 'dokploy_mysql_update'.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, dependencies, or when this creation tool should be used instead of other MySQL-related tools (like 'dokploy_mysql_deploy', 'dokploy_mysql_update', or database tools for other systems). There's no indication of appropriate contexts or constraints for tool invocation.

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

• dokploy_mysql_moveD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond what annotations already provide. It doesn't explain what 'move' entails (downtime? data transfer? permissions?), whether it's reversible, what authentication is needed, or any rate limits. With annotations covering basic safety hints, the description fails to add meaningful behavioral details.

  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 brief and front-loaded with the tool name, but it wastes space by repeating the name in brackets and including a basic parameter list that doesn't add semantic value. While not verbose, it's under-specified rather than efficiently informative. Every sentence (or line) should earn its place, and the parameter listing here doesn't provide meaningful guidance.

  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 this is a mutation tool (move operation) with 2 parameters, 0% schema description coverage, no output schema, and annotations that only provide basic hints, the description is severely incomplete. It doesn't explain the operation's purpose, behavior, parameters, or expected outcomes. For a tool that likely involves significant changes to infrastructure, this level of documentation is inadequate.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning neither parameter has any description in the schema. The description merely lists parameter names and types without explaining what 'mysqlId' or 'targetEnvironmentId' represent, their format, or where to find them. This adds minimal value beyond the schema's structural information, failing to compensate for the complete lack of schema descriptions.

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

  Purpose2/5

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

  The description restates the tool name ('mysql.move') and lists parameters without explaining what the tool actually does. It doesn't specify what 'move' means in this context (e.g., migrating a MySQL database between environments) or what resource is being moved. This is essentially a tautology of the name with parameter listing added.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or what happens after moving. Given the sibling tools include other 'move' operations (e.g., dokploy_mariadb_move, dokploy_postgres_move), there's no differentiation provided.

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

• dokploy_mysql_reloadD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a mutable operation (readOnlyHint=false) but not destructive (destructiveHint=false), not idempotent (idempotentHint=false), and operates in an open world (openWorldHint=true). The description adds no behavioral context beyond what annotations provide - no mention of what 'reload' entails operationally, whether it causes downtime, what permissions are needed, or what the expected outcome is. With annotations covering basic safety, the description fails to add meaningful behavioral insight.

  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 technically concise (two lines) but suffers from under-specification rather than efficient communication. The first line repeats the name with HTTP method, and the second lists parameters without context. While not verbose, it fails to convey necessary information, making the brevity unhelpful rather than efficient.

  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 this is a mutable operation (readOnlyHint=false) with no output schema and 0% schema description coverage, the description is severely incomplete. It doesn't explain what 'reload' means, what the parameters are for, what happens during execution, or what to expect as a result. For a database management tool that likely affects service availability, this lack of context is problematic.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description lists parameter names (mysqlId, appName) but adds no semantic meaning - no explanation of what these identifiers represent, where to find them, format requirements, or how they relate to the reload operation. For a 2-parameter tool with zero schema coverage, this minimal listing is insufficient compensation.

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

  Purpose2/5

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

  The description restates the tool name/title ('mysql.reload') without explaining what 'reload' means in this context. It doesn't specify what resource is being reloaded (MySQL service/instance) or what the reload action actually does (restart configuration, refresh connections, etc.). While it mentions 'mysql' and 'POST', this is largely tautological with the name and HTTP method.

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

  Usage Guidelines1/5

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

  The description provides zero guidance on when to use this tool versus alternatives. With siblings like dokploy_mysql_start, dokploy_mysql_stop, dokploy_mysql_rebuild, and dokploy_mysql_update, there's no indication of when a 'reload' is appropriate versus these other operations. No prerequisites, timing considerations, or comparison to similar tools are mentioned.

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

• dokploy_mysql_startD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation with open-world hints, but the description adds no behavioral context. It doesn't explain what 'start' entails (e.g., starting a service, container, or process), potential side effects, permissions required, or error conditions. With annotations providing basic safety hints, the description fails to compensate for the lack of output schema or detailed behavioral disclosure.

  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 concise but poorly structured—it mixes tool signature ('[mysql] mysql.start (POST)') with a parameter list in a non-standard format. While it avoids verbosity, the presentation is cluttered and doesn't front-load key information effectively. It could be more readable with clearer separation of concerns.

  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 (a state-changing operation with no output schema), the description is insufficient. It lacks details on what 'start' means, expected outcomes, error handling, or how it interacts with other MySQL tools. Annotations provide some hints, but without output schema or richer description, the agent lacks complete context for safe and effective use.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only lists 'mysqlId' as a required parameter without explaining its meaning, format, or how to obtain it. It doesn't clarify if this is an ID of a MySQL instance, container, or service, or provide examples. With low schema coverage, the description adds minimal semantic value beyond the bare parameter name.

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

  Purpose2/5

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

  The description restates the tool name ('mysql.start') and verb ('POST') without clarifying what 'start' means in this context. It doesn't specify whether this starts a MySQL service, container, or instance, nor does it differentiate from sibling tools like 'dokploy_mysql_stop' or 'dokploy_mysql_changeStatus'. This is a tautology that adds minimal value beyond the name/title.

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

  Usage Guidelines1/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 doesn't mention prerequisites (e.g., MySQL must be stopped), when not to use it (e.g., if already running), or refer to sibling tools like 'dokploy_mysql_stop' or 'dokploy_mysql_changeStatus'. This leaves the agent with no context for selection.

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

• dokploy_notification_testCustomConnectionD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint=true. The description adds minimal behavioral context - it mentions 'POST' which aligns with non-readOnly, but doesn't explain what 'testCustomConnection' actually does behaviorally (e.g., sends a test notification, validates connectivity, returns status). For a tool with 0% schema description coverage and no output schema, the description should provide more behavioral insight about what the test entails and what results to expect.

  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 brief and structured with a clear parameter list, but it's overly terse. The first line '[notification] notification.testCustomConnection (POST)' is redundant with the tool name/title. The parameter listing is useful but lacks explanatory context. While concise, it borders on under-specification rather than efficient communication.

  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 0% schema description coverage, no output schema, and annotations that only provide basic hints, the description is insufficiently complete. For a connection testing tool that likely sends requests to external endpoints, the description should explain what constitutes a successful test, what kind of response format to expect, error conditions, and authentication requirements. The current description leaves too many contextual gaps for effective tool selection and invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It lists 'endpoint (string, required)' and 'headers (object, optional)' but provides no semantic context about what these parameters represent, their expected formats, or usage examples. For a custom connection testing tool, the description should explain what kind of endpoint is expected (e.g., webhook URL, API endpoint) and what headers might be needed for authentication or content negotiation.

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

  Purpose2/5

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

  The description states '[notification] notification.testCustomConnection (POST)' which is essentially a restatement of the tool name and title, providing minimal additional context. It mentions 'testCustomConnection' but doesn't explain what this testing entails or what resource it operates on beyond the generic 'notification' prefix. Compared to sibling tools like dokploy_notification_testDiscordConnection, it doesn't clearly differentiate its specific purpose for custom connections.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical use cases, or when not to use it. Given sibling tools like dokploy_notification_testDiscordConnection and dokploy_notification_testEmailConnection, there's no indication of how this custom connection testing differs from provider-specific testing tools.

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

• dokploy_notification_testGotifyConnectionD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate the tool is non-read-only, non-destructive, non-idempotent, and open-world, but the description doesn't add any behavioral context beyond what annotations provide. It doesn't explain what 'test' entails (e.g., sends a notification, checks server response), potential side effects, or error handling. With annotations covering basic traits, the description adds minimal value.

  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 brief and front-loaded with the tool name, but it's under-specified rather than concise. The parameter list is included but adds little value without explanations. While not verbose, it fails to convey essential information efficiently, making it less helpful than a truly concise yet informative description.

  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 (4 parameters, 0% schema coverage, no output schema) and annotations that only cover basic hints, the description is incomplete. It lacks purpose, usage guidelines, parameter meanings, and behavioral details. For a tool that likely involves network calls and notification testing, this leaves the agent with insufficient context to use it effectively.

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

  Parameters2/5

  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 lists parameters (serverUrl, appToken, priority, decoration) but provides no semantics—no explanation of what they represent, acceptable values, or usage. For example, it doesn't clarify that 'priority' might be a Gotify priority level or that 'decoration' controls formatting. This leaves parameters largely undocumented.

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

  Purpose2/5

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

  The description restates the tool name and title ('notification.testGotifyConnection') and lists parameters, but doesn't clearly state what the tool does. It lacks a specific verb explaining the action (e.g., 'test connectivity to a Gotify server' or 'send a test notification'). The purpose is implied but not explicitly defined, making it vague and tautological.

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

  Usage Guidelines1/5

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

  There are no guidelines on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or exclusions. Given the sibling tools include other notification test tools (e.g., testDiscordConnection, testEmailConnection), the absence of differentiation is a significant gap.

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

• dokploy_notification_testPushoverConnectionD
  1.9/5.0
  Behavior2/5

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

  Annotations provide basic hints (non-readOnly, non-destructive, non-idempotent, openWorld), but the description adds almost no behavioral context. It doesn't explain what 'testing' entails - whether it sends actual notifications, validates configuration, returns diagnostic information, or has side effects. For a tool with annotations indicating it's a mutation (readOnlyHint: false) but not destructive, the description should clarify what changes or effects occur, but it provides minimal value beyond annotations.

  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 brief and structured with a parameter list, which is efficient. However, the first line '[notification] notification.testPushoverConnection (POST)' is redundant with the name/title and adds little value. The parameter listing is helpful but lacks explanations. While concise, it borders on under-specified rather than optimally informative.

  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 5 parameters with 0% schema coverage, no output schema, and annotations that only provide basic hints, the description is insufficient. It doesn't explain the tool's purpose, when to use it, what the parameters mean, what behavior to expect, or what the output might be. For a testing/mutation tool with multiple parameters, this leaves significant gaps for the agent to operate effectively.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning parameter descriptions are entirely absent from the schema. The description lists parameter names and types but provides no semantic meaning - it doesn't explain what userKey, apiToken, priority, retry, or expire represent in the context of Pushover testing. Without this context, the agent cannot understand what values to provide or their significance, making parameter selection challenging.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal context. It mentions 'notification.testPushoverConnection (POST)' which echoes the name and adds HTTP method, but doesn't explain what 'testPushoverConnection' actually does - whether it sends a test notification, validates credentials, or performs some other verification. The description fails to specify the action's outcome or purpose beyond the literal name.

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

  Usage Guidelines1/5

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

  There are no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives (like other notification test tools such as dokploy_notification_testDiscordConnection or dokploy_notification_testSlackConnection), what prerequisites exist, or what context triggers its use. The agent receives zero guidance on appropriate invocation scenarios.

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

• dokploy_notification_testResendConnectionD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate the tool is non-readOnly, non-destructive, non-idempotent, and openWorld, but the description adds no behavioral context beyond this. It doesn't explain what 'testResendConnection' entails—whether it sends a test notification, validates credentials, or performs another action. For a tool with 0% schema description coverage and no output schema, the description fails to disclose critical behavior like expected outcomes or side effects.

  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 brief and front-loaded with the tool name and method, but it's under-specified rather than concise. The parameter list is included, but without explanations, it doesn't add meaningful content. While not verbose, the structure lacks effective communication, making it inefficient rather than optimally concise.

  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 (3 parameters, 0% schema coverage, no output schema, and annotations that don't fully explain behavior), the description is incomplete. It doesn't cover what the tool does, how to use it, what parameters mean, or what to expect in return. This leaves significant gaps for the agent to understand and invoke the tool correctly.

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

  Parameters2/5

  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 lists parameters (apiKey, fromAddress, toAddresses) but provides no semantic meaning—e.g., what 'apiKey' is for, what 'fromAddress' and 'toAddresses' represent, or format requirements. This adds minimal value beyond the schema's structural information, failing to clarify parameter purposes or constraints.

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

  Purpose2/5

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

  The description restates the tool name and HTTP method ('notification.testResendConnection (POST)') but provides minimal functional context. It mentions 'notification' and 'testResendConnection' but doesn't clarify what 'testResendConnection' means—whether it's testing a connection, resending a notification, or something else. This is tautological and vague, failing to distinguish from sibling notification tools like 'testEmailConnection' or 'testSlackConnection'.

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

  Usage Guidelines1/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 lacks context about prerequisites, such as needing a configured Resend notification provider, or when this tool is appropriate compared to other notification testing tools (e.g., 'testEmailConnection'). This absence of usage instructions leaves the agent without direction.

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

• dokploy_notification_updateGotifyD
  1.9/5.0
  Behavior3/5

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

  Annotations provide clear hints (non-readOnly, non-destructive, idempotent, openWorld), but the description adds no behavioral context beyond what annotations already declare. It doesn't explain what 'update' entails (e.g., partial vs. full updates), authentication requirements, or rate limits. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

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

  Conciseness2/5

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

  While brief, the description is under-specified rather than concise. The first line is redundant, and the parameter list is a bare enumeration without explanatory context. It lacks a clear, front-loaded purpose statement, making it inefficient for quick understanding despite its short length.

  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 (14 parameters, mutation operation), lack of output schema, and 0% schema description coverage, the description is severely incomplete. It doesn't explain what the tool updates, the expected input format, or the result of the operation, leaving critical gaps for agent understanding.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning parameters are completely undocumented in the schema. The description only lists parameter names and types without explaining their purpose, relationships, or how they affect the update operation. For 14 parameters with no schema documentation, this minimal listing fails to compensate for the coverage gap.

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

  Purpose2/5

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

  The description merely repeats the tool name and HTTP method ('notification.updateGotify (POST)') without explaining what the tool actually does. It doesn't specify what resource is being updated or what 'Gotify' refers to, making it a tautology that provides no meaningful purpose statement beyond the name itself.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. With numerous sibling notification tools (createGotify, updateDiscord, updateEmail, etc.), the description fails to distinguish this tool's specific use case or context, leaving the agent with no usage direction.

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

• dokploy_patch_byEntityIdD
  1.9/5.0
  Behavior3/5

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

  Annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), which already tell the agent this is a safe, non-destructive, repeatable read operation. The description adds minimal value by mentioning '(GET)' which aligns with readOnlyHint, but doesn't provide additional behavioral context like what kind of data is returned, error conditions, or rate limits. No contradiction with annotations exists.

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

  Conciseness2/5

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

  While brief, the description is under-specified rather than concise. The first line '[patch] patch.byEntityId (GET)' is redundant with the tool name, and the parameter listing adds minimal value. The structure lacks a clear purpose statement upfront, making it inefficient for quick understanding. Every sentence should earn its place, but here the content doesn't justify its existence.

  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 has 2 parameters with 0% schema coverage, no output schema, and operates in a complex system with many sibling tools, the description is inadequate. It doesn't explain what the tool returns, how it differs from other patch tools, or provide necessary context for proper use. While annotations cover safety aspects, the description fails to address the tool's role in the broader dokploy ecosystem.

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

  Parameters1/5

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

  With 0% schema description coverage, the description must compensate but fails completely. It merely lists parameter names and types ('id (string, required), type (enum: application, compose, required)') without explaining what these parameters mean, what 'id' refers to, what 'type' selection affects, or how they relate to the tool's function. This provides no semantic value beyond what the bare schema already shows.

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

  Purpose2/5

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

  The description states '[patch] patch.byEntityId (GET)' which is tautological - it essentially repeats the tool name with minimal clarification. It doesn't specify what 'patch' means in this context (retrieve patch information? apply a patch?) or what 'byEntityId' operation actually performs. While it mentions GET, the purpose remains vague compared to the specificity needed for effective tool selection.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools in the dokploy_patch_* category (like dokploy_patch_one, dokploy_patch_create, dokploy_patch_update), there's no indication of how this tool differs or when it's appropriate to use. The description lacks any contextual usage information.

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

• dokploy_patch_saveFileAsPatchD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond the parameter list. It doesn't explain what 'saveFileAsPatch' entails (e.g., does it create a new patch file, modify an existing one, or trigger a deployment?), what side effects occur, or any permissions/rate limits needed, which is insufficient given the lack of output schema.

  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 brief and front-loaded with the tool name, but it wastes space on a redundant parameter list that adds no value beyond the schema. It could be more concise by focusing on purpose and usage instead of repeating structured data.

  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 (5 parameters, 0% schema coverage, no output schema) and annotations that only cover basic hints, the description is incomplete. It fails to explain the tool's purpose, parameter meanings, behavioral outcomes, or how it fits into the broader patch workflow, making it inadequate for an agent to use effectively.

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

  Parameters2/5

  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 by explaining parameter meanings. It only lists parameter names and types without clarifying semantics (e.g., what 'id' refers to, what 'filePath' expects, how 'content' is used, or the implications of 'patchType'). This leaves critical gaps, such as whether 'patchType' defaults or influences behavior.

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

  Purpose2/5

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

  The description restates the tool name ('patch.saveFileAsPatch') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being patched, what 'saveFileAsPatch' means operationally, or how this differs from other patch-related tools like 'dokploy_patch_create' or 'dokploy_patch_update' among the siblings.

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

  Usage Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or how it relates to other patch tools (e.g., 'dokploy_patch_create', 'dokploy_patch_update') or file operations in the sibling list, leaving the agent with no context for selection.

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

• dokploy_postgres_moveD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds no behavioral context beyond what annotations provide. For a 'move' operation, the description should clarify what happens during the move (downtime? data transfer? service interruption?), whether it's reversible, authentication requirements, or any rate limits. With annotations covering basic safety profile, the description fails to add meaningful behavioral context for a potentially complex migration operation.

  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 extremely concise but arguably under-specified rather than efficiently structured. It wastes space on redundant information ('[postgres]' repeats the tool name prefix, '(POST)' is HTTP method detail less relevant to AI agents). The parameter listing is presented but without useful context. While brief, it fails to front-load the most important information about what the tool actually does.

  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 this is a 'move' operation (potentially complex with data migration implications), no output schema, 0% parameter documentation coverage, and annotations that only provide basic safety hints, the description is severely incomplete. It doesn't explain what 'move' means operationally, what the expected outcome is, error conditions, or how to verify success. For a database migration tool, this leaves critical gaps in understanding how to use it correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description lists parameter names but adds no semantic meaning - it doesn't explain what 'postgresId' refers to (database instance ID? cluster ID?), what 'targetEnvironmentId' means, what valid values are, or how these IDs should be obtained. For a move operation with 2 required parameters at 0% schema coverage, this minimal listing is insufficient to help an agent understand what to provide.

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

  Purpose2/5

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

  The description states '[postgres] postgres.move (POST)' which is essentially a tautology - it repeats the tool name and adds HTTP method information without explaining what 'move' means in this context. It doesn't specify what resource is being moved (a PostgreSQL database/instance) or what 'move' entails (migration, relocation, transfer between environments). The parameter list provides some clues but doesn't constitute a purpose statement.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are several sibling tools with 'move' operations (dokploy_application_move, dokploy_compose_move, dokploy_mariadb_move, dokploy_mongo_move, dokploy_mysql_move, dokploy_redis_move), but no indication of when this PostgreSQL-specific move tool is appropriate versus those other move operations. No prerequisites, constraints, or alternatives are mentioned.

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

• dokploy_redis_changeStatusD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, non-idempotent operation with open-world semantics. The description adds nothing beyond what's in annotations - it doesn't explain what 'changeStatus' actually does behaviorally (does it restart a service? change operational state? update monitoring status?), what permissions might be required, or any side effects. With annotations providing basic safety hints, the description adds minimal additional context.

  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 technically concise but under-specified. It wastes characters on technical details like '[redis]' and '(POST)' that don't aid understanding, while lacking meaningful content about the tool's purpose. The parameter listing is structured but unhelpful without explanations. It's brief but not effectively informative.

  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?

  For a mutation tool with 2 parameters (0% schema coverage), no output schema, and complex sibling context, this description is severely incomplete. It doesn't explain what the tool does, when to use it, what the parameters mean, what happens when invoked, or what to expect in return. The annotations provide basic safety hints but the description fails to add the necessary contextual information for effective tool use.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It merely lists parameter names and types without explaining what 'redisId' refers to (Redis instance ID? container name? deployment identifier?) or what the applicationStatus enum values mean in context (what does 'idle' vs 'running' vs 'done' signify for a Redis service?). The description adds almost no semantic value beyond what's already visible in the schema structure.

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

  Purpose2/5

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

  The description restates the tool name ('redis.changeStatus') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being modified (a Redis instance/container?) or what 'changeStatus' means in practical terms. While it mentions 'POST', this is technical implementation detail rather than purpose clarification.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'dokploy_redis_start', 'dokploy_redis_stop', and other status-related tools for different services (mariadb_changeStatus, mongo_changeStatus, etc.), there's no indication of when this specific status change tool is appropriate versus those other tools.

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

• dokploy_redis_rebuildD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is not read-only, not destructive, not idempotent, and open-world, but the description adds no behavioral context. For a 'rebuild' operation, it doesn't clarify if data is preserved, if downtime occurs, or what the expected outcome is. With annotations covering basic hints, the description fails to add meaningful behavioral details beyond the minimal schema info.

  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 brief but inefficiently structured. It includes redundant info like '(POST)' and a parameter list that doesn't add value. While not verbose, it lacks a clear, front-loaded explanation of the tool's purpose, making it less helpful despite its conciseness.

  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 a 'rebuild' operation, no output schema, and minimal annotations, the description is incomplete. It doesn't explain what 'rebuild' does, potential side effects, or expected results. For a tool that likely involves significant system changes, this leaves critical gaps in understanding for safe and effective use.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only lists 'redisId' as a parameter without explaining what it is (e.g., an identifier for a Redis instance). It doesn't provide format examples, constraints, or where to obtain the ID. With one undocumented parameter, the description adds minimal semantic value beyond the schema's type and requirement.

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

  Purpose2/5

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

  The description states '[redis] redis.rebuild (POST)' which is a tautology of the tool name and adds minimal context. It mentions 'rebuild' but doesn't specify what resource is being rebuilt (Redis instance/database) or what 'rebuild' entails. Compared to siblings like dokploy_redis_reload or dokploy_redis_deploy, it doesn't differentiate the specific action.

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

  Usage Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, typical scenarios for rebuilding Redis, or what distinguishes it from other Redis operations like reload, deploy, or start/stop. Without this, an agent cannot make informed decisions.

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

• dokploy_redis_saveExternalPortD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, non-idempotent, open-world operation. The description adds minimal behavioral context: it implies a write ('POST') but doesn't explain what 'save' entails (e.g., whether it updates configuration, requires redeployment, or affects running services). For a mutation tool with annotations covering basic safety, the description adds little value beyond confirming it's a POST request.

  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 brief and structured with a header and parameter list, but it's under-specified rather than concise. The first line '[redis] redis.saveExternalPort (POST)' is redundant with the name and title, and the parameter listing adds little value without explanations. While not verbose, it fails to convey necessary information efficiently.

  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 a mutation tool with 2 parameters, 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is inadequate. It doesn't explain the tool's effect, parameter usage, or expected outcomes, leaving significant gaps for an agent to understand how to invoke it correctly in the context of Redis management.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types but doesn't explain their meaning (e.g., what 'redisId' refers to, what 'externalPort' represents, or that 'null' might disable the port). It adds minimal semantics beyond the schema's type information, insufficient for a tool with undocumented parameters.

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

  Purpose2/5

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

  The description restates the tool name ('redis.saveExternalPort') and lists parameters, but doesn't explain what the tool actually does. It mentions 'POST' which implies a write operation, but doesn't specify what 'saveExternalPort' means in context (e.g., configuring Redis external port). This is borderline tautological rather than clarifying purpose.

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

  Usage Guidelines1/5

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

  No guidance is provided about when to use this tool versus alternatives. There are sibling tools like 'dokploy_mariadb_saveExternalPort' and 'dokploy_postgres_saveExternalPort' for other services, but the description doesn't differentiate this Redis-specific tool or mention prerequisites. This leaves the agent with no usage context.

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

• dokploy_registry_testRegistryByIdD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readonly, non-destructive, non-idempotent operation with open-world semantics. The description adds no behavioral context beyond what annotations already provide. It doesn't explain what 'testing' a registry entails, whether it makes external calls, what side effects occur, or what the expected outcome looks like. For a POST operation that likely interacts with external systems, this is insufficient behavioral disclosure.

  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 brief but not effectively structured. It wastes space on redundant information (repeating the tool name and HTTP method) while lacking meaningful content. The parameter listing is poorly formatted and adds little value without explanations. While concise, it's under-specified rather than efficiently informative.

  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?

  For a POST operation with 2 parameters, 0% schema coverage, no output schema, and annotations that only provide basic hints, the description is severely incomplete. It doesn't explain what the tool does, when to use it, what parameters mean, what behavior to expect, or what results are returned. The combination of poor annotations coverage and inadequate description leaves the agent with insufficient information to use this tool correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning neither parameter has any description in the schema. The tool description only lists parameter names ('registryId', 'serverId') without explaining their purpose, format, or relationship. It doesn't clarify whether both are required together, what a 'registryId' refers to, or how 'serverId' relates to the registry testing operation. The description fails to compensate for the complete lack of schema documentation.

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

  Purpose2/5

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

  The description restates the tool name ('registry.testRegistryById') and HTTP method ('POST') without explaining what the tool actually does. It doesn't specify what 'testRegistryById' means - whether it validates connectivity, checks credentials, verifies configuration, or performs some other test operation. The description is tautological rather than explanatory.

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

  Usage Guidelines1/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 sibling tools include 'dokploy_registry_testRegistry' (without the 'ById' suffix), but the description provides no differentiation between these tools. No context about prerequisites, typical use cases, or when this specific tool is appropriate is provided.

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

• dokploy_schedule_createD
  1.9/5.0
  Behavior2/5

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

  The annotations provide basic hints (not read-only, not destructive, not idempotent, open world), but the description adds almost no behavioral context. It doesn't explain what happens when a schedule is created, whether it starts immediately, what permissions are required, or how it interacts with other resources. For a creation tool with 16 parameters, this minimal description fails to provide adequate behavioral transparency beyond what annotations already indicate.

  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 technically concise - it's just a parameter list with minimal preamble. However, this conciseness comes at the cost of being under-specified. The structure is clear (method signature followed by parameter list), but the content is insufficient. It's not verbose, but it's also not helpful.

  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 (16 parameters, creation operation), lack of output schema, and 0% schema description coverage, the description is severely incomplete. It doesn't explain what a schedule does in this system, what gets created, what the expected response looks like, or how to verify successful creation. For a tool that presumably creates scheduled tasks in a deployment system, this minimal description leaves too many questions unanswered.

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

  Parameters2/5

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

  With 0% schema description coverage and 16 parameters (13 optional, 3 required), the description merely lists parameter names and types without explaining their meaning, relationships, or constraints. It doesn't clarify what 'cronExpression' format is expected, how 'scheduleType' relates to other parameters like 'applicationId' or 'composeId', or what 'any' type parameters accept. The description fails to compensate for the complete lack of schema descriptions.

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

  Purpose2/5

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

  The description is essentially a tautology - it restates the tool name 'schedule.create' without explaining what a 'schedule' is in this context or what the tool actually does. While it mentions it's a POST operation, it doesn't specify what resource is being created or what the schedule controls. It fails to distinguish this from sibling schedule tools like dokploy_schedule_list, dokploy_schedule_update, or dokploy_schedule_delete.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this should be used instead of other schedule tools, or what context requires schedule creation. With multiple sibling schedule tools available, this complete lack of usage guidance is problematic.

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

• dokploy_server_buildServersD
  1.9/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already convey safety and idempotency. The description adds no behavioral context beyond what annotations provide, such as what 'buildServers' means operationally, whether it triggers processes, or what the response contains. However, it doesn't contradict annotations.

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

  Conciseness2/5

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

  While concise, the description is under-specified rather than efficiently informative. A single bracketed phrase provides no useful content, failing to front-load purpose or usage. This isn't effective conciseness but rather a lack of necessary detail.

  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 likely complexity (inferred from sibling tools involving server operations), the description is severely incomplete. With no output schema and minimal annotations, the description fails to explain what 'buildServers' entails, what it returns, or how it differs from other server tools, leaving critical gaps for agent 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 parameters and 100% schema description coverage, the schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate as it doesn't create confusion about parameters.

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

  Purpose1/5

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

  The description '[server] server.buildServers (GET)' is a tautology that merely restates the tool name and HTTP method without explaining what the tool actually does. It provides no specific verb or resource information, failing to distinguish it from sibling tools like 'dokploy_server_all' or 'dokploy_server_create'.

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

  Usage Guidelines1/5

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

  There are no usage guidelines provided. The description offers no indication of when to use this tool versus alternatives, what context it's appropriate for, or any prerequisites. This leaves the agent with no guidance on selection among the many server-related sibling tools.

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

• dokploy_sshKey_generateD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond what annotations provide (e.g., it doesn't explain what 'generate' entails—whether it returns a key, stores it, requires authentication, or has side effects). With annotations covering basic hints, the description adds minimal value, but for a creation-like tool, more context is needed.

  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 brief but poorly structured—it mixes tool path, HTTP method, and parameter list without clear separation. It's front-loaded with '[sshKey] sshKey.generate (POST)', but the content is minimal and could be more organized. While not verbose, it lacks effective communication, making it mediocre in conciseness.

  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 likely creates something (implied by 'generate' and POST), annotations provide some safety hints, but there's no output schema. The description doesn't explain what is returned (e.g., key pair, success status) or any operational details. With 0% schema coverage and no output schema, the description is incomplete for effective use.

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

  Parameters2/5

  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 lists the parameter 'type' with enum values, but this is already clear from the schema. It doesn't explain what 'type' means (e.g., algorithm choice), default behavior if omitted, or other semantics. With 1 parameter and no schema descriptions, the description adds only redundant information, failing to provide meaningful context.

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

  Purpose2/5

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

  The description restates the tool name ('sshKey.generate') and adds the HTTP method (POST), which is tautological. It doesn't specify what the tool actually does (e.g., generate a new SSH key pair, return a public key, store it somewhere). The title and name are identical, providing no additional clarity. However, it does mention the resource ('sshKey'), preventing a score of 1.

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

  Usage Guidelines1/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. Sibling tools include 'dokploy_sshKey_create', 'dokploy_sshKey_all', etc., but the description doesn't differentiate this tool from them (e.g., whether this generates a key while 'create' might store it). No context, prerequisites, 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_stripe_upgradeSubscriptionD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond what annotations provide - no mention of billing implications, permission requirements, rate limits, or what happens to the existing subscription. With annotations covering basic safety, the description adds minimal value.

  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 brief but inefficiently structured. It wastes space repeating the tool name and 'POST' method, then provides a minimal parameter list. While concise, it fails to use its limited space effectively to convey meaningful information.

  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?

  For a subscription upgrade tool with 3 parameters, 0% schema coverage, no output schema, and annotations that only cover basic safety, the description is severely incomplete. It doesn't explain the operation's effects, return values, error conditions, or relationship to billing systems - critical context for a financial transaction tool.

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

  Parameters2/5

  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 merely lists parameter names and types without explaining their meaning (what 'tier' represents, what 'serverQuantity' measures, what 'isAnnual' affects). This adds almost no semantic value beyond what the bare schema provides.

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

  Purpose2/5

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

  The description restates the tool name ('stripe.upgradeSubscription') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being upgraded (presumably a Stripe subscription) or what 'upgrade' entails. This is closer to a tautology than a clear purpose statement.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing subscription), when this operation is appropriate, or what other tools might be relevant (like downgrade or cancel). This leaves the agent with no usage context.

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

• dokploy_user_assignPermissionsD
  1.9/5.0
  Behavior2/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds no behavioral context beyond what annotations provide. For a permission assignment tool with 15 required parameters, the description should explain what happens when permissions are assigned (e.g., whether they replace existing permissions, merge with them, require specific user roles to invoke, or have validation rules). The description provides only parameter listings without behavioral insight.

  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 reasonably concise - just a header and parameter list. However, it's poorly structured as it leads with a redundant restatement of the name and HTTP method rather than the tool's purpose. The parameter list is clear but lacks organization (e.g., grouping related permissions). It's brief but not effectively structured for understanding.

  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?

  For a complex permission management tool with 15 required parameters, no output schema, and annotations that only cover basic hints, the description is severely incomplete. It doesn't explain the tool's purpose, when to use it, what the parameters mean, what the tool returns, or any behavioral expectations. The agent would struggle to use this tool correctly given the minimal information provided.

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

  Parameters2/5

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

  With 0% schema description coverage and 15 parameters, the description merely lists parameter names without explaining their meaning. While it shows which parameters are arrays vs booleans, it doesn't explain what 'accessedProjects' contains (project IDs? names?), what the boolean flags control, or how the arrays interact with the boolean permissions. The description fails to compensate for the complete lack of schema descriptions.

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

  Purpose2/5

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

  The description restates the tool name as '[user] user.assignPermissions (POST)' without explaining what 'assignPermissions' means. It lists parameters but doesn't state the tool's purpose - whether it assigns permissions to a user, modifies existing permissions, or creates new permission sets. The name suggests it's about user permissions, but the description doesn't clarify the action or resource beyond what's already in the name/title.

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

  Usage Guidelines1/5

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

  There are no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives, what prerequisites exist, or what context it's appropriate for. With many sibling tools in the system, there's no guidance on when this specific permission assignment tool should be selected over other user or permission management tools.

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

• dokploy_application_searchC
  2/5.0
  Behavior3/5

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

  Annotations provide comprehensive safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description doesn't need to repeat these. However, it adds no behavioral context beyond what annotations already cover - no information about pagination behavior (implied by limit/offset), authentication requirements, rate limits, or what constitutes a successful search.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently structured. It wastes space repeating the tool name and 'GET' method without providing meaningful content. The parameter list format is readable but doesn't compensate for the lack of actual description content.

  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?

  For a search tool with 11 parameters, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't explain what 'searching applications' means, how results are returned, what the filtering logic is (AND/OR), or provide any examples. The annotations help with safety but don't address core functionality gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It merely lists parameter names without any semantic explanation of what they filter (e.g., 'q' for general search, 'name' vs 'appName' distinction, 'projectId' for scoping). This adds minimal value beyond the schema's type information.

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

  Purpose2/5

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

  The description restates the tool name ('application.search') and lists parameters without explaining what the tool actually does. It doesn't specify that this searches for applications or what resource it operates on, making it a tautology of the name rather than a clear purpose statement.

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

  Usage Guidelines1/5

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

  No guidance is provided about when to use this tool versus alternatives. With many sibling tools like 'dokploy_application_one' (get single application) and other search tools (e.g., 'dokploy_environment_search'), the description offers no context about when this search is appropriate versus other lookup methods.

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

• dokploy_backup_updateC
  2/5.0
  Behavior3/5

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

  Annotations provide significant behavioral information (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds no behavioral context beyond what annotations already declare - it doesn't mention what gets updated, whether this requires specific permissions, rate limits, or what happens to existing backup configurations. However, since annotations cover the core safety profile, the description meets the lower bar but adds minimal value.

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

  Conciseness2/5

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

  The description is under-specified rather than concise. It wastes space on a redundant header ('[backup] backup.update (POST)') and presents a parameter list that duplicates the schema without adding value. The structure doesn't front-load essential information about the tool's purpose. While brief, it's not effectively concise as it fails to communicate necessary information efficiently.

  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?

  For a mutation tool (update operation) with 10 parameters, 0% schema description coverage, no output schema, and no sibling differentiation, the description is severely incomplete. It doesn't explain what gets updated, what the expected outcome is, how to identify the backup to update, or what happens to existing settings. The annotations help somewhat, but the description fails to provide the contextual information needed for proper tool invocation.

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

  Parameters2/5

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

  With 0% schema description coverage and 10 parameters (9 required), the description carries full burden for explaining parameter meanings. While it lists parameter names and types, it provides no semantic context about what each parameter represents (e.g., what 'schedule' format to use, what 'keepLatestCount' controls, what 'metadata' should contain). The parameter list is essentially a restatement of the schema without added meaning, failing to compensate for the schema's lack of descriptions.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal context ('backup.update (POST)'). It mentions 'backup' but doesn't specify what aspect of a backup is being updated (configuration, schedule, settings, etc.). While it lists parameters, this doesn't constitute a clear purpose statement. The description fails to provide a specific verb+resource combination that distinguishes this tool's function.

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

  Usage Guidelines1/5

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

  The description provides zero guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, when this operation is appropriate, or what distinguishes it from sibling backup tools like 'dokploy_backup_create', 'dokploy_backup_one', or 'dokploy_backup_remove'. Without any usage context, an agent cannot make informed decisions about tool selection.

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

• dokploy_bitbucket_createC
  2/5.0
  Behavior3/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. However, the description adds no behavioral context beyond what annotations provide—it doesn't explain what 'create' entails (e.g., whether it persists data, requires authentication, or has side effects), leaving gaps for a mutation tool.

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

  Conciseness2/5

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

  While brief, the description is under-specified rather than concise—it wastes space on a redundant header ('[bitbucket] bitbucket.create (POST)') and a bare parameter list without meaningful context. The structure doesn't front-load key information about the tool's purpose.

  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 (9 parameters, mutation tool), lack of output schema, and minimal annotations, the description is incomplete. It doesn't explain what is created, the expected inputs, the outcome, or error conditions, making it inadequate for effective tool invocation.

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

  Parameters2/5

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

  With 0% schema description coverage and 9 parameters (7 optional, 2 required), the description merely lists parameter names without explaining their purpose, relationships, or semantics. For example, it doesn't clarify what 'bitbucketId', 'appPassword', or 'authId' represent, or how they interact, failing to compensate for the lack of schema documentation.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name ('bitbucket.create') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being created (e.g., a Bitbucket provider configuration, repository connection, or integration), nor does it distinguish this from sibling tools like dokploy_bitbucket_update or dokploy_bitbucket_one.

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

  Usage Guidelines1/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 doesn't mention prerequisites, when this should be called, or what alternatives exist among the many sibling tools (e.g., dokploy_gitea_create, dokploy_github_update).

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

• dokploy_cluster_addManagerC
  2/5.0
  Behavior3/5

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

  Annotations provide comprehensive hints (readOnly=true, destructive=false, idempotent=true, openWorld=true), so the agent knows this is a safe, repeatable query operation. The description adds minimal value beyond annotations - it mentions the HTTP method (GET) which aligns with readOnlyHint, but doesn't describe what the operation actually does behaviorally (what 'addManager' means in practice, what the response contains, or any side effects).

  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 extremely brief (two lines) but not effectively structured. It front-loads the tool name repetition rather than useful information. While concise, it wastes its limited space on redundant details rather than providing value. The parameter listing is minimal but doesn't add understanding.

  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 cluster management operations and the complete lack of output schema, the description is inadequate. Annotations cover safety aspects, but the description doesn't explain what the tool actually accomplishes, what 'addManager' means, what the response looks like, or how it relates to other cluster tools. For a tool that presumably modifies cluster configuration (despite being read-only per annotations), this leaves too many unanswered questions.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description only lists 'serverId (string, optional)' without explaining what a serverId is, where to find it, what format it should have, or what happens when it's omitted. For a single parameter with no schema documentation, the description fails to provide any meaningful semantic context about this critical input.

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

  Purpose2/5

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

  The description restates the tool name ('cluster.addManager') and adds '(GET)' which is tautological. It doesn't explain what 'addManager' actually does - whether it adds a manager node to a cluster, assigns a manager role to a server, or something else. The verb 'add' is vague without specifying the resource being added or the outcome.

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

  Usage Guidelines1/5

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

  No guidance is provided about when to use this tool versus alternatives. With sibling tools like 'dokploy_cluster_addWorker', 'dokploy_cluster_getNodes', and 'dokploy_cluster_removeWorker', there's no indication of how this tool differs from those or when it's appropriate to use. The description offers no context about prerequisites, timing, or relationships 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_cluster_addWorkerC
  2/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable operation. The description adds that it's a GET method, which is consistent with read-only behavior, but doesn't disclose additional traits like rate limits, authentication needs, or what 'addWorker' entails beyond the method. No contradiction with annotations exists.

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

  Conciseness2/5

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

  The description is under-specified, not concise. It includes redundant formatting like brackets and 'GET', but lacks essential information in a structured way. Sentences like 'Parameters: - serverId (string, optional)' are minimal but don't earn their place by adding value, making it inefficient rather than brief.

  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 cluster operations, no output schema, and annotations covering safety, the description is incomplete. It doesn't explain the outcome (e.g., what happens after adding a worker), error conditions, or how it integrates with other tools like 'dokploy_cluster_getNodes'. For a tool with 0% schema coverage and no output details, it should provide more context.

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

  Parameters2/5

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

  Schema description coverage is 0%, with one optional parameter 'serverId' of type string. The description lists 'serverId (string, optional)' but adds no meaning beyond the schema, such as what serverId refers to (e.g., target server identifier) or its role in adding a worker. With low coverage, it fails to compensate for the lack of schema details.

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

  Purpose2/5

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

  The description states 'cluster.addWorker (GET)' which partially indicates adding a worker to a cluster via GET method, but it's vague about what 'addWorker' actually does (e.g., provisions, joins, or registers a worker). It doesn't distinguish from sibling tools like 'dokploy_cluster_addManager' or 'dokploy_cluster_removeWorker', leaving the specific action unclear.

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

  Usage Guidelines1/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 versus alternatives is provided. The description lacks context about prerequisites, when it's appropriate (e.g., scaling clusters), or comparisons to siblings like 'dokploy_cluster_addManager' or 'dokploy_cluster_getNodes', making it misleading for selection.

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

• dokploy_gitea_updateC
  2/5.0
  Behavior3/5

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

  Annotations indicate the tool is not read-only, not destructive, idempotent, and open-world, which provides basic behavioral traits. The description adds no context beyond this, such as what specific updates are allowed, side effects, or error conditions. However, it does not contradict the annotations, so it meets the lower bar with annotations present but adds minimal value.

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

  Conciseness2/5

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

  The description is under-specified, not concise. It wastes space on a redundant header and a bare parameter list without explanatory text. A single sentence explaining the tool's purpose would be more effective. The structure is poor as it lacks a clear, front-loaded purpose statement.

  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 (15 parameters, 4 required), no output schema, and 0% schema coverage, the description is incomplete. It does not explain what the tool updates, the expected input formats, or the return value. Annotations provide some behavioral context, but the description fails to address the tool's role in the system or its interactions with siblings.

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

  Parameters2/5

  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 by explaining parameter meanings. It only lists parameter names and types without any semantics, such as what 'giteaId' refers to or how 'expiresAt' is formatted. This fails to add meaningful context beyond the schema, leaving 15 parameters largely unexplained.

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

  Purpose2/5

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

  The description merely restates the tool name as '[gitea] gitea.update (POST)' and lists parameters without explaining what the tool actually does. It fails to specify the action (e.g., updates a Gitea provider configuration) or the resource being modified, making it a tautology of the name/title. No differentiation from siblings like 'dokploy_gitea_create' or 'dokploy_gitea_one' is provided.

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

  Usage Guidelines1/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 prerequisites, context (e.g., when updating vs. creating a Gitea provider), or exclusions. Sibling tools like 'dokploy_gitea_create' and 'dokploy_gitea_one' exist, but no comparison is made, leaving the agent without usage direction.

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

• dokploy_licenseKey_activateC
  2/5.0
  Behavior3/5

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

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these (it implies a write action with 'activate', consistent with readOnlyHint=false). However, it adds minimal behavioral context beyond annotations—no details on what 'activate' entails (e.g., whether it enables features, starts a subscription), potential side effects, or error conditions. For a mutation tool with annotations, this is a baseline level of transparency.

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

  Conciseness2/5

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

  The description is under-specified, not concise. It wastes space on redundant formatting ('[licenseKey] licenseKey.activate (POST)') and a basic parameter list without useful details. The structure doesn't front-load key information; it lacks a clear purpose statement upfront. While brief, it's inefficient due to missing essential content.

  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 (a mutation with no output schema and 0% schema coverage), the description is incomplete. It doesn't explain the outcome of activation (e.g., success response, error cases), how it interacts with other license tools, or system implications. Annotations provide some safety hints, but the description fails to add necessary context for effective use, especially for a parameter-heavy operation.

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

  Parameters2/5

  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 only lists the parameter name ('licenseKey') without explaining its format (e.g., alphanumeric string, where to obtain it), purpose (e.g., a purchased key), or constraints (e.g., length, pattern). This adds little meaning beyond the schema's type and minLength, failing to address the coverage gap adequately.

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

  Purpose2/5

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

  The description restates the tool name ('licenseKey.activate') and lists the parameter, which is tautological. It doesn't explain what 'activate' means in this context (e.g., enabling a license for use, registering it with the system). While it mentions the required parameter, it fails to provide a clear verb+resource statement that distinguishes it from sibling tools like 'dokploy_licenseKey_deactivate' or 'dokploy_licenseKey_validate'.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid license key), when activation is required (e.g., after purchase, during setup), or what happens if the key is already active. With sibling tools like 'deactivate' and 'validate', there's no indication of how they relate, leaving the agent to guess based on names alone.

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

• dokploy_mariadb_rebuildC
  2/5.0
  Behavior3/5

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

  Annotations provide useful information (non-readOnly, non-destructive, non-idempotent, openWorld), but the description adds minimal behavioral context. It doesn't explain what 'rebuild' entails operationally - whether it recreates containers, resets data, reconfigures settings, or causes downtime. However, it doesn't contradict the annotations, and the POST method hint suggests a mutation operation consistent with readOnlyHint=false.

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

  Conciseness2/5

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

  While technically concise, the description is under-specified rather than efficiently informative. The two-line format with bracketed category and HTTP method is structured but fails to convey meaningful information. Every sentence should earn its place, and this description doesn't provide enough value to justify even its minimal length.

  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?

  For a mutation tool (POST) with no output schema and minimal annotations, the description is inadequate. It doesn't explain what 'rebuild' means operationally, what the expected outcome is, whether there are side effects, or what happens to existing data. Given the complexity implied by a database rebuild operation and the lack of output documentation, this description leaves too many questions unanswered.

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

  Parameters2/5

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

  With 0% schema description coverage for the single required parameter 'mariadbId', the description provides no additional semantic information. It merely lists the parameter name without explaining what a mariadbId is, where to find it, what format it uses, or how it identifies the MariaDB resource to rebuild. This leaves the parameter completely undocumented beyond its existence.

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

  Purpose2/5

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

  The description '[mariadb] mariadb.rebuild (POST)' is essentially a tautology that restates the tool name and HTTP method without explaining what 'rebuild' actually does. It doesn't specify what resource is being rebuilt (database instance, container, configuration) or what the outcome is. While it mentions 'mariadb', it doesn't distinguish this from sibling tools like dokploy_mariadb_reload or dokploy_mariadb_deploy.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, typical scenarios for rebuilding, or what distinguishes this from other MariaDB operations like reload, restart, or redeploy. With multiple sibling tools for MariaDB management, this lack of differentiation is problematic.

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

• dokploy_mariadb_updateC
  2/5.0
  Behavior3/5

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

  Annotations indicate this is a non-destructive, idempotent update operation (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description doesn't contradict these annotations, but it also adds no behavioral context beyond what's already in annotations. It doesn't explain what 'update' means in practice (e.g., partial updates, validation, side effects, or response format). With annotations covering basic safety, the description adds minimal value.

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

  Conciseness2/5

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

  While the description is technically concise in length, it's poorly structured and wastes space on a redundant parameter list that duplicates the schema. The first line '[mariadb] mariadb.update (POST)' is the only content that isn't just schema repetition, but it's insufficient. This isn't effective conciseness—it's under-specification masked as brevity.

  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 (32 parameters, mutation operation, no output schema), the description is severely incomplete. It doesn't explain the update operation's scope, what happens to unspecified parameters, whether all parameters are optional except mariadbId, or what the response contains. With annotations providing only basic hints and no output schema, the description fails to provide necessary context for effective use.

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

  Parameters2/5

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

  The description merely lists parameter names and types without any semantic explanation. With 0% schema description coverage (no parameter descriptions in the schema), the description fails to compensate by explaining what parameters like 'mariadbId', 'databaseRootPassword', or 'modeSwarm' actually mean or how they affect the update. This leaves 32 parameters largely unexplained.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name ('mariadb.update') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being updated (a MariaDB database instance/configuration) or what the update operation entails. While it mentions 'POST' which implies a write operation, this is insufficient for purpose clarity.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites, when this should be used instead of other MariaDB tools (like create, delete, or deploy), or any contextual constraints. This leaves the agent with no usage direction.

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

• dokploy_mongo_deployC
  2/5.0
  Behavior3/5

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

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds that it's a POST request, implying a write action, which aligns with annotations. However, it lacks details on what 'deploy' specifically does (e.g., starts a service, provisions resources), potential side effects, or error conditions, leaving behavioral context incomplete.

  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 brief but poorly structured; it mixes tool context ('[mongo] mongo.deploy (POST)') with a parameter list in a non-standard format. While concise, it lacks clear separation of purpose and parameters, making it less readable. It avoids redundancy but sacrifices clarity for brevity.

  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 (a deployment operation with one parameter), lack of output schema, and minimal annotations, the description is insufficient. It doesn't explain the outcome of deployment, success indicators, or integration with sibling tools like dokploy_mongo_create. For a non-idempotent write tool, more context is needed to ensure correct usage.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description only lists 'mongoId (string, required)' without explaining what this parameter represents (e.g., an identifier for a MongoDB configuration, instance, or resource). It fails to add any semantic meaning beyond the schema, such as format examples, constraints, or where to obtain the ID, which is critical given the low coverage.

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

  Purpose2/5

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

  The description '[mongo] mongo.deploy (POST)' restates the name/title with minimal additional information. It mentions 'mongo' and 'deploy' but doesn't specify what resource is being deployed (e.g., a MongoDB database instance, container, or service) or what the deployment entails. This is a tautology that provides little value beyond the tool name itself.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. Given the many sibling tools (e.g., dokploy_mongo_create, dokploy_mongo_start, dokploy_mongo_stop), there is no indication of prerequisites, typical workflow, or distinctions from related operations. This leaves the agent without context for tool selection.

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

• dokploy_mongo_saveEnvironmentC
  2/5.0
  Behavior3/5

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

  Annotations indicate this is a mutable operation (readOnlyHint=false) that is non-destructive and non-idempotent, with open-world semantics. The description doesn't add any behavioral details beyond these annotations, such as what 'save' entails (e.g., overwriting existing environment variables, merging, or appending), authentication requirements, or rate limits. However, it doesn't contradict the annotations, so it meets the baseline for annotations covering safety aspects.

  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 concise but poorly structured. It includes a redundant prefix ('[mongo] mongo.saveEnvironment (POST)') that repeats the tool name and adds HTTP method info, which isn't necessary for an AI agent. The parameter listing is minimal but doesn't add value. It's front-loaded with noise rather than purpose.

  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 (a write operation with 2 parameters), lack of output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the operation's effect, return values, error conditions, or how it fits into the broader context of MongoDB management (e.g., compared to 'dokploy_mongo_update'). This leaves significant gaps for an agent to understand and use the tool correctly.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description lists parameters ('mongoId', 'env') but adds no semantic meaning—it doesn't explain what 'mongoId' refers to (e.g., a MongoDB instance identifier) or what 'env' should contain (e.g., key-value pairs for environment variables). This fails to compensate for the lack of schema documentation.

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

  Purpose2/5

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

  The description restates the tool name and title ('mongo.saveEnvironment') without clarifying what 'saveEnvironment' actually does. It doesn't specify what resource is being saved (e.g., environment variables for a MongoDB instance) or distinguish it from similar sibling tools like 'dokploy_mariadb_saveEnvironment' or 'dokploy_mysql_saveEnvironment'. This is borderline tautological.

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

  Usage Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing MongoDB instance), context (e.g., during deployment or configuration), or related tools (e.g., 'dokploy_mongo_update' for other modifications). This leaves the agent with no usage context.

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

• dokploy_notification_updateDiscordC
  2/5.0
  Behavior3/5

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

  Annotations provide good behavioral information (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds no behavioral context beyond what annotations already declare. It doesn't explain what 'update' entails, whether it modifies existing Discord notification settings, what happens with partial updates, or any side effects. With annotations covering the safety profile, a baseline 3 is appropriate as the description adds no value beyond structured data.

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

  Conciseness2/5

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

  The description is poorly structured - it starts with a redundant line that adds little value, then presents a parameter list without context. While it's not verbose, it's under-specified rather than concise. The information is presented as a raw parameter dump rather than a helpful description, making it difficult for an agent to understand the tool's purpose quickly.

  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 (13 parameters, 2 required), 0% schema description coverage, no output schema, and the fact this is a mutation tool (update operation), the description is severely incomplete. It doesn't explain what a Discord notification is in this system, what fields can be updated, what the expected response looks like, or how this tool fits into the notification system. The annotations help but don't compensate for the missing contextual information.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning none of the 13 parameters have descriptions in the schema. The description simply lists parameter names and types without explaining what they mean or how they're used. While it does enumerate all parameters, it provides no semantic meaning beyond basic type information. For a tool with 13 parameters and 0% schema coverage, this is inadequate compensation.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal context. It states '[notification] notification.updateDiscord (POST)' which just repeats the name and adds the HTTP method, but doesn't explain what the tool actually does. There's no clear verb+resource statement explaining what 'updateDiscord' means in this context.

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

  Usage Guidelines1/5

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

  There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives, what prerequisites exist, or how it relates to sibling tools like dokploy_notification_createDiscord or dokploy_notification_updateEmail. The agent receives zero guidance on appropriate usage context.

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

• dokploy_notification_updateLarkC
  2/5.0
  Behavior3/5

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

  Annotations provide hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), indicating it's a non-destructive, idempotent mutation. The description adds no behavioral context beyond this, such as what 'update' entails (e.g., partial vs. full updates) or any side effects. However, it does not contradict annotations, so it meets the lower bar with annotations present.

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

  Conciseness2/5

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

  The description is poorly structured, starting with redundant name/HTTP method and then dumping a parameter list without explanation. It is under-specified rather than concise, wasting space on unhelpful repetition instead of providing meaningful content.

  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 12 parameters (2 required), 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is incomplete. It lacks purpose, usage, parameter semantics, and behavioral details, making it inadequate for a mutation tool with many parameters.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameter names and types but adds no semantic meaning (e.g., what 'appBuildError' controls or how 'webhookUrl' is used). This fails to compensate for the low coverage, leaving parameters largely unexplained.

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

  Purpose2/5

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

  The description merely restates the tool name and title with '[notification] notification.updateLark (POST)' and lists parameters, failing to articulate what the tool actually does. It does not specify the action (e.g., update settings for a Lark notification) or the resource involved, making it tautological and unclear.

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

  Usage Guidelines1/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, such as other notification update tools (e.g., updateDiscord, updateEmail) or createLark. The description lacks context, prerequisites, or exclusions, leaving the agent with no usage direction.

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

• dokploy_notification_updatePushoverC
  2/5.0
  Behavior3/5

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

  Annotations indicate this is a non-destructive, idempotent update operation (readOnlyHint: false, destructiveHint: false, idempotentHint: true). The description doesn't contradict these, but it adds no behavioral context beyond what annotations provide—such as authentication requirements, rate limits, or what happens to unspecified fields during an update. With annotations covering safety, a baseline 3 is appropriate, though more detail would improve utility.

  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 concise but poorly structured. It front-loads the tool name and HTTP method, followed by a bare parameter list. While not verbose, the parameter list lacks explanatory value and could be better organized (e.g., grouping related parameters). It avoids redundancy but misses opportunities for clarity, making it adequate but not helpful.

  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 (16 parameters, 0% schema coverage, no output schema) and annotations that only cover basic safety, the description is incomplete. It fails to explain the tool's role in the notification system, parameter meanings, or expected outcomes. For an update tool with many optional flags, more context is needed to guide effective use, leaving significant gaps for the agent.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning no parameters are documented in the schema. The description merely lists parameter names and types without explaining their purpose, relationships, or constraints (e.g., what 'priority' values mean, what 'retry' and 'expire' control, or how boolean flags like 'appBuildError' affect notifications). For 16 parameters with zero schema coverage, this minimal listing is insufficient to compensate.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name ('notification.updatePushover') with minimal additional context. It lacks a clear verb-resource-action statement explaining what the tool actually does (e.g., 'Update a Pushover notification configuration in Dokploy'). While it mentions 'notification' and 'updatePushover', it doesn't articulate the purpose beyond what's implied by 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 Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'dokploy_notification_createPushover' and other notification update tools (e.g., for Discord, Email), there's no indication of prerequisites, when this tool is appropriate, or what distinguishes it from creating a new notification. This leaves the agent without context for selection.

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

• dokploy_notification_updateTeamsC
  2/5.0
  Behavior3/5

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

  Annotations provide good coverage (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description doesn't need to repeat these. However, the description adds no behavioral context beyond what annotations already provide - no information about what gets updated, how notifications work, what happens to existing settings, or any rate limits/permissions needed. The description neither contradicts nor meaningfully supplements the annotations.

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

  Conciseness2/5

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

  The description is poorly structured - it starts with redundant information '[notification] notification.updateTeams (POST)' and then provides a parameter list that belongs in the schema. The content is not front-loaded with purpose, and the parameter listing adds bulk without adding meaningful context. This is under-specification rather than true conciseness.

  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?

  For a tool with 12 parameters, no output schema, and no schema descriptions, the description is inadequate. It doesn't explain what the tool returns, what the update operation entails, or how it relates to the broader notification system. While annotations provide some behavioral context, the description fails to provide the necessary semantic understanding for proper tool selection and invocation.

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

  Parameters2/5

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

  With 0% schema description coverage and 12 parameters (10 optional, 2 required), the description merely lists parameter names and types without explaining their meaning or purpose. While it provides a structured list, it doesn't add semantic understanding - for example, what do 'appBuildError' or 'serverThreshold' actually control? The description fails to compensate for the complete lack of schema descriptions.

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

  Purpose2/5

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

  The description is essentially a tautology that restates the tool name with minimal context. It mentions '[notification] notification.updateTeams (POST)' which indicates it's a notification-related update operation for Teams, but doesn't specify what is being updated or what the tool actually does. It fails to distinguish this from sibling notification tools like dokploy_notification_updateDiscord or dokploy_notification_updateSlack.

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

  Usage Guidelines1/5

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

  There are no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives, what prerequisites exist, or what context would make this the appropriate choice. With many sibling notification tools available, this lack of guidance is particularly problematic.

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

• dokploy_organization_deleteC
  2/5.0
  Behavior3/5

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

  The annotations provide significant behavioral information: destructiveHint=true indicates permanent deletion, readOnlyHint=false confirms it's a mutation, idempotentHint=false suggests non-idempotent behavior, and openWorldHint=true implies it may accept unknown organization IDs. The description adds no behavioral context beyond what annotations already declare. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  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 brief with two lines, but it's poorly structured and includes redundant information. The first line '[organization] organization.delete (POST)' is confusing and adds little value. The parameter listing is minimal. While concise, it lacks effective front-loading of useful information and includes formatting that doesn't enhance clarity.

  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?

  For a destructive deletion tool with 1 parameter, 0% schema coverage, no output schema, and rich annotations, the description is inadequate. It doesn't explain the consequences of deletion, what happens to associated resources, or any confirmation requirements. The annotations cover safety aspects, but the description should provide more operational context given the tool's critical nature.

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

  Parameters1/5

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

  The description lists 'organizationId (string, required)' as a parameter, but this merely repeats what the input schema already shows with 0% schema description coverage. It adds no semantic meaning about what organizationId represents, format expectations, or how to obtain valid IDs. With low schema coverage, the description fails to compensate for the lack of parameter documentation.

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

  Purpose2/5

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

  The description states '[organization] organization.delete (POST)' which is essentially a restatement of the tool name and title, with minimal added clarity. It mentions 'delete' as the verb and 'organization' as the resource, but lacks specificity about what deletion entails or its scope. This is a tautology that provides little 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 Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include dokploy_organization_all, dokploy_organization_one, dokploy_organization_create, and dokploy_organization_update, there is no indication of when deletion is appropriate versus other organization operations. There are no prerequisites, warnings, or contextual usage instructions.

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

• dokploy_patch_updateC
  2/5.0
  Behavior3/5

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

  Annotations provide hints: readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), openWorldHint=true (accepts unknown fields). The description adds no behavioral context beyond what annotations already cover. It doesn't mention side effects, permissions, or response format. Since annotations are present and not contradicted, the bar is lower, but the description adds no value here.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is poorly structured: it starts with redundant '[patch] patch.update (POST)', then lists parameters without context. It's not front-loaded with purpose, and the parameter list is verbose without adding explanatory value. While brief, it's inefficient due to under-specification rather than true conciseness.

  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 with 0% schema coverage, no output schema, and annotations that only hint at safety, the description is incomplete. It doesn't explain what a patch is, what fields are updatable, or the expected outcome. For a mutation tool with many optional parameters, this leaves significant gaps for an agent to understand and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters with basic types but provides no semantic meaning (e.g., what 'patchId' identifies, what 'content' contains, what 'enabled' controls). This adds minimal value beyond the schema, failing to clarify usage. With 7 parameters and no schema descriptions, this is inadequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description essentially restates the tool name 'patch.update' with the HTTP method 'POST', which is tautological. It doesn't explain what a 'patch' is in this context (e.g., a code patch, configuration patch) or what specific resource is being updated. While it lists parameters, it doesn't articulate the core action 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 Guidelines1/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 sibling tools include 'dokploy_patch_create', 'dokploy_patch_delete', and 'dokploy_patch_toggleEnabled', but the description doesn't differentiate this update tool from those or specify prerequisites like needing an existing patch. It provides no context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_project_duplicateC
  2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description doesn't add behavioral details beyond this, such as what 'duplicate' entails (e.g., whether it creates a new project or environment, if it copies configurations, or any side effects). However, it doesn't contradict the annotations, so it meets the baseline for having annotations but adds minimal context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is under-specified, not concise. It wastes space on a redundant header ('[project] project.duplicate (POST)') and a bare parameter list without explanations. The structure is inefficient, as it doesn't front-load key information about the tool's purpose or usage.

  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 (6 parameters, no output schema, annotations only cover basic hints), the description is incomplete. It lacks details on what the tool does, when to use it, parameter meanings, and expected outcomes. This leaves significant gaps for an agent to understand and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameter names and types but provides no semantic meaning (e.g., what 'sourceEnvironmentId' refers to, what 'includeServices' controls, or the purpose of 'selectedServices'). This adds little value beyond the schema, failing to address the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('[project] project.duplicate (POST)') without explaining what 'duplicate' means in this context. It lists parameters but doesn't state the action's purpose (e.g., creating a copy of a project environment). This is tautological rather than clarifying the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'dokploy_environment_duplicate' and 'dokploy_project_create', the description doesn't differentiate this tool's use case, leaving the agent without context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_updateC
  2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds minimal behavioral context beyond annotations. Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, idempotent, open-world operation. The description only adds that it's a POST request, which implies it's an update operation. However, it doesn't provide crucial behavioral details like authentication requirements, rate limits, what happens when specific fields are updated, or whether the update is partial/full. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise, the description is under-specified rather than efficiently structured. It wastes space listing 24 parameter names without adding value, instead of providing meaningful context. The structure shows the HTTP method but doesn't front-load the most important information about what the tool does and when to use it. Every sentence (or in this case, the parameter listing) doesn't earn its place by adding explanatory value.

  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 (24 parameters, mutation operation, no output schema, 0% schema coverage), the description is severely incomplete. It doesn't explain what a successful update returns, error conditions, required versus optional fields, field dependencies, or the update's effect on the system. For a user management tool with many sensitive fields (password, ban status, payment info), this lack of context is particularly problematic.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage for 24 parameters, the description carries full burden for explaining parameters. It merely lists parameter names without any semantic explanation of what they mean, their relationships, or constraints. For example, it doesn't explain that 'id' or 'email' might be required for identification, what 'createdAt2' versus 'createdAt' represents, or the format for dates. The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology - it restates the tool name 'user.update' without adding meaningful context about what the tool actually does. While it mentions 'POST' which indicates an HTTP method, it doesn't explain what resource is being updated or the scope of the operation. The description fails to distinguish this from sibling tools like 'dokploy_user_remove' or 'dokploy_user_get'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives, what permissions are required, whether it's for admin vs regular users, or any prerequisites. With many sibling tools available (like dokploy_user_remove, dokploy_user_get, dokploy_user_createApiKey), the agent has no guidance on when this specific update tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_volumeBackups_updateC
  2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is not read-only, not destructive, idempotent, and open-world, but the description adds no behavioral context beyond this. It does not explain what 'update' entails (e.g., modifies backup settings), potential side effects, or any constraints like permissions or rate limits. Since annotations provide basic safety hints, the description adds minimal value, scoring a baseline 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is poorly structured, starting with a redundant header and dumping a parameter list without explanation. It is not front-loaded with purpose, and the parameter list is verbose without adding value, making it inefficient and hard to parse quickly.

  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 (20 parameters, 0% schema coverage, no output schema) and annotations, the description is incomplete. It lacks essential details like what the tool updates (e.g., backup schedule settings), expected outcomes, or error conditions, making it inadequate for effective tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 20 parameters, the description lists parameter names and types but adds no semantic meaning (e.g., what 'cronExpression' controls or how 'serviceType' relates to other IDs). It fails to compensate for the lack of schema documentation, leaving most parameters unexplained beyond their basic types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description merely repeats the tool name '[volumeBackups] volumeBackups.update (POST)' and lists parameters without stating what the tool does. It fails to specify the action (e.g., 'update configuration of a volume backup schedule') or the resource involved, making it tautological and unclear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 like 'dokploy_volumeBackups_create' or 'dokploy_volumeBackups_delete'. The description provides no context, prerequisites, or exclusions, leaving the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_admin_setupMonitoringC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, idempotent, open-world operation, which the description does not contradict. However, the description adds little behavioral context beyond what annotations provide—it hints at a POST request but doesn't explain effects like whether this enables monitoring, requires admin privileges, or impacts system performance. With annotations covering safety traits, the description adds minimal value, scoring a baseline 3.

  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 brief but inefficiently structured—it includes administrative details like '[admin]' and 'POST' without front-loading the tool's purpose. While concise, it wastes space on redundant information (name restatement) instead of providing actionable insights, making it less helpful despite its short length.

  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 (nested schema, no output schema, 0% schema coverage), the description is inadequate. It fails to explain the tool's role in monitoring setup, expected outcomes, or error conditions. With annotations providing some behavioral hints but no output schema, the description should offer more context to guide the agent effectively, but it does not, leaving significant gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 by explaining parameter meanings. It only lists 'metricsConfig (object, required)' without detailing what this config includes (e.g., server and container settings, thresholds) or its purpose. Given the complex nested schema with 1 parameter but many sub-properties, this lack of semantic information leaves the agent guessing about required inputs, resulting in a low score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('admin.setupMonitoring') without adding meaningful context about what the tool actually does. It mentions 'POST' and lists a parameter, but fails to specify the action (e.g., configure, enable, initialize monitoring) or the resource affected (e.g., server monitoring, container metrics). This is tautological and provides minimal clarity 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 Guidelines1/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 prerequisites, context (e.g., after server setup, for admin users only), or related tools (e.g., dokploy_server_getServerMetrics for reading metrics). Without any usage instructions, the agent lacks direction on appropriate invocation scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_ai_deleteC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide destructiveHint=true (indicating permanent deletion) and readOnlyHint=false (confirms mutation). The description adds the HTTP method (POST) which isn't in annotations, but doesn't elaborate on behavioral aspects like confirmation requirements, error conditions, or what 'aiId' represents. No contradiction with annotations, but minimal additional context.

  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 brief but poorly structured. It includes the HTTP method and parameter list, but the formatting with brackets and line breaks is awkward. While concise, it lacks clear front-loading of the core purpose and reads more like a technical specification snippet.

  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?

  For a destructive operation with no output schema and 0% schema coverage, the description is inadequate. It doesn't explain the consequences of deletion, success/error responses, or relationship to other AI tools. Annotations cover safety aspects, but the description fails to provide necessary operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description only lists 'aiId (string, required)' without explaining what an AI ID is, where to find it, format constraints, or examples. This adds minimal semantic value beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'ai.delete (POST)' which restates the tool name and HTTP method without explaining what resource it deletes. It mentions 'aiId' parameter but doesn't clarify this deletes an AI instance/model. Compared to siblings like 'dokploy_ai_create' and 'dokploy_ai_update', the purpose is only slightly distinguished by the 'delete' verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 versus alternatives. The description doesn't mention prerequisites (e.g., existing AI to delete), when deletion is appropriate, or what happens after deletion. No comparison to sibling tools like 'dokploy_ai_remove' (not present) or other deletion tools in the system.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_ai_getC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the bar is lower. The description adds minimal value by indicating this is a GET operation, which aligns with the annotations. However, it doesn't disclose any additional behavioral traits like what specific AI resource is retrieved, authentication requirements, rate limits, 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 extremely brief - just one line with minimal formatting. While concise, it's under-specified rather than efficiently informative. The structure with 'Parameters:' heading is somewhat organized, but the content lacks substance. Every sentence should earn its place, and here the single line provides little value beyond what's already evident from the tool name.

  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 AI management tools and the lack of output schema, the description is insufficient. With rich annotations but 0% schema description coverage and no output schema, the description should explain what this tool returns (e.g., AI configuration details, model information) and provide more context about the 'aiId' parameter. The current description leaves too many gaps for effective tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation in the schema. The description lists 'aiId (string, required)' which simply repeats the parameter name and type from the schema without adding any semantic meaning. It doesn't explain what an 'aiId' represents, where to find it, format constraints, or example values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[ai] ai.get (GET)' is essentially a tautology that restates the tool name and HTTP method without explaining what the tool actually does. It mentions 'ai.get' which mirrors the tool name 'dokploy_ai_get', and adds '(GET)' which is redundant with the title. There's no clear statement of purpose like 'retrieve AI configuration' or 'fetch AI model details'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'dokploy_ai_getAll', 'dokploy_ai_one', and 'dokploy_ai_getModels', there's no indication of when this specific 'get' operation is appropriate versus those other retrieval tools. No context, prerequisites, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_ai_getModelsC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already communicate this is a safe, repeatable read operation. The description adds no behavioral context beyond what annotations provide - no information about authentication requirements, rate limits, pagination, or what 'models' actually represents. However, it doesn't contradict the annotations, so it meets the lower bar with annotations present.

  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 brief but inefficiently structured. It leads with '[ai] ai.getModels (GET)' which adds little value, then lists parameters without context. While concise, it's not well-structured for understanding - the most important information (what the tool does) is missing, making the conciseness feel like under-specification rather than efficiency.

  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?

  For a tool with 2 parameters, 0% schema description coverage, no output schema, and rich annotations, the description is incomplete. It doesn't explain what 'models' are, what format they're returned in, or how the parameters are used. The annotations cover safety aspects, but the description fails to provide necessary context about the tool's domain and expected behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for the 2 parameters. The description lists parameter names and types but adds no semantic meaning - it doesn't explain what apiUrl should point to, what format the apiKey requires, or how these parameters relate to getting models. With low schema coverage, the description fails to compensate adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'ai.getModels (GET)' which restates the name/title and HTTP method without explaining what the tool actually does. It doesn't specify what 'models' refers to (AI models, data models, etc.) or what action is performed (list, retrieve, etc.). This is a tautology that provides minimal value beyond the tool name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like dokploy_ai_get, dokploy_ai_getAll, and dokploy_ai_one, there's clear need for differentiation, but the description offers no context about scope, filtering, or when this specific tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_ai_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the bar is lower. The description adds minimal value by specifying 'GET' as the HTTP method, which aligns with the read-only nature indicated by annotations. However, it doesn't provide additional context about what 'ai.one' represents, authentication requirements, rate limits, or response format.

  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 extremely brief - just two lines. While this is technically concise, it's under-specified rather than efficiently informative. The structure with 'Parameters:' heading is clear, but the content lacks substance. Every sentence should earn its place, and here the minimal content doesn't provide adequate guidance for tool selection and invocation.

  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 apparent purpose (retrieving AI-related data), the lack of output schema, and minimal annotations context, the description is incomplete. It doesn't explain what 'ai.one' represents, what data is returned, or how this differs from similar sibling tools. For a tool that likely retrieves specific AI configuration or status information, the description leaves too many unanswered questions about its function and appropriate usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and only one parameter (aiId), the description should compensate but fails to do so. The description lists 'aiId (string, required)' but provides no context about what an aiId is, where to find valid values, or what format it should follow. This adds almost no semantic meaning beyond what the bare schema already indicates through its type and required constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[ai] ai.one (GET)' which is tautological - it essentially repeats the tool name 'dokploy_ai_one' with minimal clarification. It doesn't specify what resource 'ai.one' refers to or what the GET operation actually retrieves. While it mentions 'GET' as the HTTP method, this doesn't explain the tool's functional purpose beyond what's already implied by 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. With sibling tools like 'dokploy_ai_get', 'dokploy_ai_getAll', and 'dokploy_ai_getModels' available, there's no indication of how this tool differs or when it should be selected. The description doesn't mention any prerequisites, context requirements, or exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_ai_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), which the description doesn't contradict. However, the description adds no additional behavioral context beyond what annotations already cover, such as explaining what 'update' entails, potential side effects, or error conditions. With annotations present, the bar is lower, but the description fails to supplement them meaningfully.

  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 concise but under-specified, consisting of a minimal header and a parameter list. While it avoids redundancy, it lacks a clear, front-loaded purpose statement and essential context. The structure is basic, with parameters listed but not well-integrated into explanatory 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 (7 parameters, 0% schema coverage, no output schema) and annotations that only partially cover behavior, the description is incomplete. It fails to explain the tool's purpose, usage, parameter meanings, or expected outcomes, making it inadequate for an agent to understand and invoke the tool effectively without additional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, placing full burden on the description to explain parameters. The description merely lists parameter names and types without adding semantic meaning, constraints, or examples (e.g., what 'aiId' identifies, format of 'createdAt', purpose of 'isEnabled'). It doesn't compensate for the lack of schema descriptions, leaving parameters largely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name 'ai.update' with minimal context. It lacks a specific verb-resource combination that explains what 'ai' refers to or what kind of update operation is performed. While it lists parameters, it doesn't articulate the tool's purpose 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'dokploy_ai_create' or 'dokploy_ai_get', nor does it specify prerequisites, conditions, or exclusions for usage. This leaves the agent with no contextual decision-making information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide basic hints (non-readOnly, non-destructive, non-idempotent, openWorld), but the description adds minimal value beyond this. It mentions 'POST' which implies a write operation (consistent with readOnlyHint=false), but doesn't disclose any behavioral traits like what happens on duplicate creation, whether there are side effects, authentication requirements, or rate limits. The description doesn't contradict annotations, but adds almost no useful context about the tool's behavior.

  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 technically concise (just two lines plus a parameter list), but this conciseness comes at the cost of being under-specified. The structure is somewhat organized with a clear parameter list, but the core description '[application] application.create (POST)' is poorly formatted and uninformative. Every sentence should earn its place, and the parameter list without explanations doesn't add sufficient value.

  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 this is a creation tool (implied mutation) with no output schema, 5 parameters (2 required), 0% schema description coverage, and annotations that only provide basic hints, the description is woefully incomplete. It doesn't explain what gets created, what the expected response looks like, error conditions, or any contextual information needed to use this tool effectively. The description fails to provide the necessary completeness for a tool with this level of complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 5 parameters (2 required), the description merely lists parameter names and basic types without explaining what they mean. It doesn't clarify what 'name' vs 'appName' represent, what 'environmentId' refers to, or what 'serverId' is for. The description adds almost no semantic value beyond what's already in the schema's property names, failing to compensate for the complete lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('application.create') and provides a parameter list without explaining what an 'application' is in this context. It doesn't specify what resource is being created (e.g., a deployment application, a web app, a service) or what the tool actually does beyond the obvious 'create' action. While it mentions 'POST' which indicates an HTTP method, this doesn't clarify the functional purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools like 'dokploy_compose_create', 'dokploy_mariadb_create', and 'dokploy_application_update', there's no indication of what distinguishes this creation tool from others, what prerequisites might exist, or in what context it should be invoked.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_deployC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide useful hints (non-readOnly, non-destructive, non-idempotent, openWorld), but the description adds minimal behavioral context. It doesn't explain what 'deploy' entails operationally, whether it triggers builds, restarts services, or has side effects. The description doesn't contradict annotations, but adds little beyond them.

  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 brief but inefficiently structured. The first line repeats the tool name, and the parameter list is minimal without explanatory value. While not verbose, it fails to use its limited space effectively to convey necessary information.

  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?

  For a deployment tool with no output schema and minimal annotations, the description is inadequate. It doesn't explain what happens during deployment, what the expected outcome is, potential errors, or how it differs from related tools. The combination of sparse description and missing output schema leaves significant gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 3 parameters, the description only lists parameter names without explaining their meaning. It doesn't clarify what 'applicationId' refers to, what 'title' and 'description' modify during deployment, or provide any semantic context beyond the bare parameter list.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name '[application] application.deploy (POST)' which is essentially a tautology of the tool name. It doesn't explain what 'deploy' means in this context or what resource is being deployed. While it mentions 'application', it doesn't clarify what type of application or deployment action occurs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'dokploy_application_redeploy', 'dokploy_application_start', and 'dokploy_ai_deploy', there's no indication of when deployment is appropriate versus other lifecycle operations or which specific deployment tool to choose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already indicate this is a safe, repeatable read operation. The description adds no behavioral context beyond what annotations provide, such as what data is returned, error conditions, or rate limits. However, it doesn't contradict the annotations.

  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 brief and front-loaded with the tool name and method, but it's inefficiently structured with a parameter list that adds little value. It could be more concise by integrating the parameter info into a clearer purpose statement, but it avoids unnecessary verbosity.

  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 implied by sibling tools and the lack of output schema, the description is insufficient. It doesn't explain what an 'application' is in this context, what data is returned, or how this fits into the broader application management workflow. Annotations cover safety, but the description fails to provide necessary operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists 'applicationId (string, required)' but adds no semantic meaning—it doesn't explain what an applicationId is, where to find it, or its format. This minimal information doesn't adequately compensate for the lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and adds '(GET)' and a parameter list, but it's essentially a tautology that doesn't explain what the tool actually does. It doesn't specify what 'application.one' means or what resource it retrieves, and it doesn't distinguish this from sibling tools like 'dokploy_application_get' or 'dokploy_application_search'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'dokploy_application_get', 'dokploy_application_search', and 'dokploy_application_getAll', there's no indication of when this specific 'one' tool is appropriate, what prerequisites exist, or what context it serves.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_readAppMonitoringC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide strong hints (readOnly, non-destructive, idempotent, openWorld), so the bar is lower. The description adds minimal context by implying it's a GET operation, but doesn't disclose behavioral traits like what monitoring data is returned, format, rate limits, or authentication needs. It doesn't contradict annotations, so no penalty.

  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 brief but not front-loaded with useful information. It wastes space on redundant details like '(GET)' and a basic parameter list without explanation. However, it's not overly verbose, so it avoids a lower score.

  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 (monitoring implies data retrieval), lack of output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what monitoring data is fetched, the return format, or error conditions. Annotations help but don't fully compensate for these gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'appName' as a required string parameter but adds no semantic meaning (e.g., what constitutes a valid appName, examples, or how it relates to monitoring). This is inadequate given the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('application.readAppMonitoring') without adding meaningful context. It mentions 'GET' which is redundant with readOnlyHint, and lists the parameter but doesn't explain what 'readAppMonitoring' actually does (e.g., retrieves monitoring data for an application). This is closer to tautology than clear purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The sibling list includes many application-related tools (e.g., dokploy_application_one, dokploy_application_search, dokploy_application_readTraefikConfig), but the description doesn't differentiate this tool from them or specify prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_redeployC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description doesn't add any behavioral context beyond these annotations (e.g., what 'redeploy' entails, whether it causes downtime, if it's asynchronous, or what happens to existing deployments). It doesn't contradict annotations but adds minimal value.

  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 brief but inefficiently structured—it includes a redundant endpoint path ('application.redeploy (POST)') and a parameter list without explanations. It's front-loaded with minimal useful information, but the parameter section could be more informative.

  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 (a redeployment operation with 3 parameters), lack of output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain the redeployment process, expected outcomes, error conditions, or how it differs from similar tools, leaving significant gaps for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (applicationId, title, description) but provides no semantic meaning (e.g., what applicationId refers to, what title/description are used for, format requirements). This adds little beyond the schema's property names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('application.redeploy') without explaining what 'redeploy' means in this context. It mentions parameters but doesn't specify what the tool actually does (e.g., triggers a redeployment of an application, restarts containers, rebuilds from source). This is closer to tautology than clear purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 like 'dokploy_application_deploy', 'dokploy_application_reload', or 'dokploy_compose_redeploy'. The description provides no context about prerequisites, timing, or differences from sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_reloadC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive (destructiveHint=false), non-idempotent (idempotentHint=false), open-world (openWorldHint=true) operation. The description adds minimal behavioral context by specifying it's a POST request, implying it triggers an action, but doesn't elaborate on effects like downtime, permissions needed, or response format. Since annotations cover basic safety, the description's addition is limited, warranting a baseline score.

  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 brief but not optimally structured; it front-loads with '[application] application.reload (POST)' which is somewhat redundant, followed by a parameter list. While concise, it lacks efficiency as the parameter info could be better integrated or omitted since it adds minimal value, making it feel under-specified rather than tightly crafted.

  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 (a mutable action with 2 parameters), annotations provide basic hints, but there's no output schema. The description fails to explain what 'reload' entails, expected outcomes, error conditions, or how it differs from siblings, leaving significant gaps for an agent to understand and use the tool correctly in context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters 'appName' and 'applicationId' as required but provides no semantic meaning (e.g., what these identifiers represent, format examples, or their relationship). This adds little beyond the schema's structural info, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'application.reload (POST)' which implies reloading an application, but it's essentially a tautology of the tool name 'dokploy_application_reload'. It doesn't specify what 'reload' means in this context (e.g., restarting services, refreshing configuration) or distinguish it from similar sibling tools like 'dokploy_application_restartContainer' or 'dokploy_application_redeploy'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. With many sibling tools for application management (e.g., start, stop, redeploy, restartContainer), the description offers no context on prerequisites, typical use cases, or exclusions, leaving the agent to guess based on the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_saveBitbucketProviderC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. However, the description adds no behavioral context beyond annotations, such as what 'save' entails (e.g., creating or updating a provider), authentication needs, or side effects. With annotations providing basic hints, the description meets a minimal baseline but adds no extra value.

  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 concise but poorly structured: it starts with a redundant restatement of the name, then lists parameters without context. While not verbose, it lacks front-loaded clarity and wastes space on a parameter list that doesn't enhance understanding.

  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 (9 parameters, 0% schema coverage, no output schema) and annotations, the description is incomplete. It doesn't explain the tool's purpose, usage, or parameter meanings, making it inadequate for an agent to understand how to invoke it correctly in context with sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists parameter names without explaining their purposes (e.g., what 'bitbucketRepositorySlug' is, how 'watchPaths' are used). This fails to add meaningful semantics beyond the schema, leaving parameters largely undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description merely restates the tool name and title ('application.saveBitbucketProvider') and lists parameters without explaining what the tool actually does. It doesn't specify the action (e.g., 'save' or 'configure') or the resource being affected, making it tautological and vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. Given the sibling tools include other provider-saving tools (e.g., saveGithubProvider, saveGitlabProvider), the lack of differentiation or context for choosing Bitbucket is a significant omission.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_saveDockerProviderC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), which the description does not contradict. However, the description adds no behavioral context beyond what annotations provide—such as what 'saveDockerProvider' entails (e.g., configuring Docker registry credentials for an application), potential side effects, or authentication requirements. With annotations covering basic safety, the description adds minimal value.

  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 brief but inefficiently structured—it front-loads redundant name/HTTP method details and then lists parameters without explanation. While not verbose, it wastes space on unhelpful content rather than conveying useful information, making it less effective than it could be for its length.

  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, 0% schema coverage, and annotations only covering basic hints), the description is highly incomplete. It lacks purpose, parameter semantics, usage context, and behavioral details, making it inadequate for an agent to understand and correctly invoke this mutation tool in a system with many siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameter names but provides no semantic meaning—e.g., what 'dockerImage', 'username', 'password', etc., represent or how they are used. This adds little beyond the schema's structural information, failing to clarify the purpose or format of parameters for a tool with 5 required inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('application.saveDockerProvider') and HTTP method ('POST') without explaining what the tool actually does. It lists parameters but provides no functional purpose statement. This is essentially a tautology of the name/title with added technical details but no meaningful explanation of the tool's action or goal.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 any context, prerequisites, or comparisons with sibling tools like other 'save...Provider' tools (e.g., saveBitbucketProvider, saveGithubProvider). This leaves the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_saveGitProviderC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. However, the description adds minimal behavioral context beyond the POST method hint. It doesn't explain what 'save' entails (e.g., whether it creates or updates Git provider settings, potential side effects like triggering deployments, or authentication needs). With annotations providing basic safety hints, the description adds some value 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 concise but poorly structured. It front-loads with a tautological statement and then lists parameters without grouping or explanation. While not verbose, the structure doesn't effectively communicate purpose or usage, making it inefficient despite its brevity.

  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 (7 parameters, mutation operation), lack of output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool does, when to use it, parameter meanings, or expected outcomes. Annotations provide some behavioral hints, but the description fails to add necessary context for effective tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description lists parameter names but offers no semantic meaning (e.g., what 'customGitBranch' represents, format of 'customGitUrl', or purpose of 'watchPaths'). This fails to compensate for the schema's lack of descriptions, leaving parameters largely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('application.saveGitProvider') and lists parameters without explaining what the tool actually does. It doesn't specify what resource it acts on (e.g., an application's Git provider configuration) or what 'save' means in this context (create, update, or configure). While it mentions POST method, this doesn't clarify the purpose 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 Guidelines1/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 doesn't mention prerequisites (e.g., needing an existing application), context (e.g., setting up Git integration), or differentiate it from sibling tools like 'dokploy_application_saveGithubProvider' or 'dokploy_application_disconnectGitProvider'. This leaves the agent with no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_updateTraefikConfigC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide good coverage (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the agent knows this is a non-destructive, idempotent mutation. The description adds minimal behavioral context beyond annotations - it specifies this is a POST operation, implying it sends data to update something. However, it doesn't describe what happens when the update succeeds/fails, whether it triggers redeployment, or any rate limits/permission requirements.

  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 technically concise (two lines) but poorly structured. It front-loads the tool name (which is already known) rather than the purpose. The parameter listing is formatted but lacks explanatory value. While brief, it wastes its limited space on redundant information rather than providing helpful context.

  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?

  For a mutation tool that updates configuration (potentially affecting application routing/behavior), this description is incomplete. There's no output schema, and the description doesn't explain what returns (success confirmation, error details, updated config). With 0% schema description coverage and no behavioral context about what 'Traefik config' means in this system, an agent would struggle to use this tool correctly without additional documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description lists parameter names and types but adds almost no semantic meaning. It doesn't explain what 'applicationId' refers to (UUID, name, etc.), what format 'traefikConfig' should be in (YAML, JSON, raw config text), or what valid values look like. This leaves both parameters essentially undocumented despite being required.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name/title ('application.updateTraefikConfig') without providing meaningful context about what the tool actually does. It mentions parameters but doesn't explain what 'updating Traefik config' means in practice - whether this modifies routing rules, middleware, or other Traefik settings for an application. This is essentially a tautology that adds little 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing an existing application), when this operation is appropriate versus other configuration methods, or what the sibling tool 'dokploy_application_readTraefikConfig' (which presumably reads the config) is for. The agent receives no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_manualBackupPostgresC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond that. It doesn't explain what 'manual' entails (e.g., triggers an immediate backup, may affect system performance), authentication needs, rate limits, or what happens on success/failure. With annotations covering basic hints, the description adds minimal value, scoring a baseline 3.

  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 brief but not efficiently structured; it includes redundant elements like '[backup]' and '(POST)' that don't add clarity, and the parameter listing is minimal without context. While not verbose, it lacks front-loaded purpose and wastes space on tautology, making it less helpful than it could be for its length.

  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 (a manual backup operation for PostgreSQL), lack of output schema, and low schema description coverage, the description is incomplete. It doesn't cover what the tool returns (e.g., backup status, file location), error conditions, or dependencies, leaving significant gaps for the agent to infer usage in a potentially critical operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists 'backupId (string, required)' without explaining what a backupId is (e.g., identifier of a backup configuration or target), where to find it, or format examples. This adds little meaning beyond the schema's type and requirement, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name with minimal clarification ('[backup] backup.manualBackupPostgres (POST)'), which is tautological. It mentions 'backup' and 'manualBackupPostgres' but doesn't specify what resource is being backed up (e.g., a PostgreSQL database instance) or distinguish it from sibling backup tools like 'manualBackupCompose' or 'manualBackupMysql'. The purpose is vague 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., requires an existing backup configuration), timing (e.g., for on-demand backups), or comparisons to automated backups or other database backup tools in the sibling list. This leaves the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive behavioral hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description's burden is lower. However, the description adds minimal value beyond what annotations already convey - it only confirms the HTTP method (GET) which aligns with readOnlyHint. It doesn't disclose any additional behavioral traits like rate limits, authentication requirements, response format, or what specifically 'backup.one' means operationally.

  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 extremely concise (two lines) but this brevity comes at the cost of clarity. The first line '[backup] backup.one (GET)' is cryptic and unhelpful, while the parameter listing is minimal. While there's no wasted text, the description is under-specified rather than efficiently informative. The structure with a parameter list is reasonable but the content is insufficient.

  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 annotations provide good behavioral coverage but schema description coverage is 0% and there's no output schema, the description is incomplete. For a tool with one required parameter, the description should explain what backupId represents and what the tool returns. The sibling tools suggest this is part of a backup management system, but the description fails to situate this tool within that context or explain its specific role.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation in the schema. The description only lists 'backupId (string, required)' without explaining what a backupId is, where to find valid values, format constraints, or examples. Given the low schema coverage and single parameter, this minimal documentation represents a significant gap in parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[backup] backup.one (GET)' is tautological, essentially restating the tool name and HTTP method without specifying what the tool actually does. It doesn't clearly state whether this retrieves backup details, downloads a backup, or performs some other operation on a backup resource. The sibling tools list shows several backup-related tools (create, listBackupFiles, manualBackup*, remove, update), but this description fails to distinguish itself from them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. With multiple backup-related siblings (dokploy_backup_create, dokploy_backup_listBackupFiles, dokploy_backup_remove, dokploy_backup_update), the agent receives no indication whether this is for retrieving metadata, downloading content, or some other specific backup operation. There's no mention of prerequisites, constraints, or appropriate contexts for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_bitbucket_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description doesn't contradict these (it mentions 'GET' which aligns with read-only). However, it adds minimal behavioral context beyond annotations - only implying it's a GET operation. No additional details about authentication needs, rate limits, or what specific Bitbucket data is retrieved are provided, leaving gaps despite good annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief but under-specified rather than concise. It uses a bracketed format '[bitbucket] bitbucket.one (GET)' followed by a parameter list, which is somewhat structured. However, the first line is redundant with the name/title, and the parameter listing adds little value without context. While not verbose, it fails to efficiently convey necessary information.

  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 1 parameter with 0% schema coverage, no output schema, and annotations covering safety but not functionality, the description is incomplete. It doesn't explain what the tool returns (Bitbucket provider details, repository list, etc.), how the bitbucketId is used, or what 'bitbucket.one' refers to. For a tool in a complex system with many siblings, this leaves too much ambiguity about its specific role and output.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'bitbucketId (string, required)' without explaining what this ID represents (provider ID, repository ID, configuration ID), where to find it, or its format. The description adds no meaningful semantics beyond what's minimally evident from the parameter name. With 0% schema coverage and inadequate parameter explanation, this falls below the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[bitbucket] bitbucket.one (GET)' is essentially a tautology that restates the tool name and HTTP method. It doesn't specify what action is performed (retrieve, fetch, get details) or what resource is being accessed (a Bitbucket provider, repository, configuration). While it mentions 'bitbucket.one' and 'GET', it lacks a clear verb+resource statement that distinguishes this from sibling tools like 'dokploy_bitbucket_bitbucketProviders' or 'dokploy_bitbucket_create'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are multiple Bitbucket-related tools in the sibling list (e.g., 'dokploy_bitbucket_bitbucketProviders', 'dokploy_bitbucket_create', 'dokploy_bitbucket_update'), but the description doesn't indicate whether this tool retrieves a specific Bitbucket provider, fetches Bitbucket repositories, or serves another purpose. No context, exclusions, or prerequisites are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_bitbucket_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (write operation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (can create new resources). The description adds no behavioral context beyond what annotations already declare. It doesn't explain what 'update' means in practice (e.g., partial vs full updates, validation behavior, or what happens with missing optional fields). No contradiction with annotations exists, but with annotations covering basic safety profile, the description adds minimal value.

  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 technically concise (just a parameter list), but it's poorly structured for understanding. It front-loads with '[bitbucket] bitbucket.update (POST)' which is redundant with the tool name, then presents a bare parameter list without grouping or explanation. While not verbose, it fails to use its limited space effectively to convey purpose or usage.

  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?

  For a mutation tool with 9 parameters (3 required), 0% schema description coverage, no output schema, and rich sibling context (multiple git provider tools), this description is severely incomplete. It doesn't explain what the tool updates, what the parameters mean, what the expected outcome is, or how it relates to other Bitbucket/git provider operations. The annotations provide basic safety hints but don't compensate for the missing functional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides only type/requirement information without any semantic meaning. The description merely lists parameter names without explaining what they represent (e.g., what bitbucketId refers to, what gitProviderId is, or how name is used). For 9 parameters with no schema descriptions, this is inadequate compensation. The description adds almost no value beyond what's already visible in the parameter names themselves.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('bitbucket.update') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being updated (e.g., a Bitbucket provider configuration) or what the update operation entails. While it mentions 'POST', this is technical implementation detail rather than functional purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include dokploy_bitbucket_create, dokploy_bitbucket_one, and dokploy_bitbucket_testConnection, there's clear need for differentiation (e.g., when to update vs create a Bitbucket provider, or when to use this versus other git provider update tools like dokploy_github_update). No usage context, prerequisites, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_certificates_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide basic hints (not read-only, not destructive, not idempotent, open world), but the description adds minimal value beyond this. It doesn't disclose important behavioral traits like whether this creates new certificates from scratch or imports existing ones, what happens on duplicate names, or any rate limits. However, it doesn't contradict the annotations, so it gets a baseline score for adding some context through the parameter list.

  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 concise but under-specified. It wastes space on redundant information like '(POST)' and the parameter list formatting. The structure is poor - it doesn't front-load the purpose, and the parameter list lacks meaningful organization. However, it's not excessively 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?

  For a certificate creation tool with 8 parameters (4 required), 0% schema coverage, no output schema, and no annotations covering mutation behavior, this description is inadequate. It doesn't explain what the tool returns, what happens on success/failure, or provide any context about certificate management in Dokploy. The description fails to compensate for the lack of structured documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description carries full burden for explaining parameters. While it lists all 8 parameters with basic types, it provides no semantic meaning - no explanation of what certificateData should contain, what format privateKey expects, what autoRenew controls, or what organizationId/serverId refer to. The parameter list adds minimal value beyond what's already in the schema structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[certificates] certificates.create (POST)' which is essentially a tautology - it restates the tool name and adds the HTTP method. It doesn't explain what the tool actually does (creates SSL/TLS certificates in Dokploy) or what resource it operates on. While it mentions 'certificates', it doesn't specify what kind of certificates or their purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There are no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives like dokploy_certificates_all (list certificates) or dokploy_certificates_remove (delete certificates). It also doesn't mention prerequisites, dependencies, or typical use cases for certificate creation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_cluster_getNodesC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover read-only, non-destructive, idempotent, and open-world hints, so the description doesn't need to repeat these. It adds minimal context by implying a GET operation, but doesn't disclose behavioral traits like response format, pagination, or error handling. With annotations providing safety profile, a baseline 3 is appropriate as the description adds little beyond structured data.

  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 brief but under-specified, not truly concise. It includes the tool path and parameter list, but the structure is minimal and lacks explanatory content. While not verbose, it doesn't efficiently convey necessary information, making it adequate but with clear gaps.

  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 (retrieving cluster nodes), annotations provide safety hints, but there's no output schema and schema coverage is 0%. The description doesn't explain what 'nodes' are, the return format, or usage context, leaving significant gaps for the agent to understand and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'serverId (string, optional)' but doesn't explain what 'serverId' refers to (e.g., a server identifier, its purpose, or valid values). This adds minimal meaning beyond the schema's type and optionality, failing to fully address the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'cluster.getNodes (GET)' which restates the name/title and HTTP method without explaining what 'getNodes' means. It doesn't specify what resource is retrieved (e.g., cluster nodes, their status, or details) or distinguish it from sibling tools like 'dokploy_swarm_getNodes'. This is a tautology with minimal added value.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 versus alternatives is provided. The description lacks context, prerequisites, or exclusions, and doesn't reference sibling tools for comparison. This leaves the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_cleanQueuesC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true (implying data loss or irreversible changes) and readOnlyHint=false (a write operation), which the description does not contradict. However, the description adds minimal behavioral context beyond the annotations—it specifies the HTTP method (POST) and parameter, but does not explain what 'cleanQueues' entails (e.g., deleting pending tasks, clearing logs, or resetting states), rate limits, or side effects. With annotations covering safety, the description provides some value 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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets and parentheses) and lacks efficient structuring. The parameter listing is minimal but could be more integrated; overall, it avoids verbosity but under-specifies key details.

  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 has destructive annotations, no output schema, and 0% schema description coverage, the description is incomplete. It does not explain the outcome of cleaning queues (e.g., what is returned or affected), error conditions, or how it interacts with other compose operations, leaving significant gaps for a mutation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'composeId' as a required parameter but provides no semantic meaning (e.g., what a composeId is, where to find it, or format examples). This adds little beyond the schema's structural info, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'compose.cleanQueues (POST)' which implies it cleans queues for a compose, but this is essentially a tautology of the tool name 'dokploy_compose_cleanQueues'. It lacks a specific verb and resource explanation (e.g., what 'queues' refer to in this context, such as deployment or task queues), and does not distinguish it from sibling tools like 'dokploy_application_cleanQueues' or 'dokploy_settings_cleanAllDeploymentQueue'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., after deployments or for maintenance), or compare it to similar tools in the sibling list, leaving the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide basic hints (not read-only, not destructive, not idempotent, open-world), but the description adds minimal behavioral context. It mentions 'POST' which implies a write operation, consistent with annotations. However, it doesn't disclose important behavioral traits like what happens on duplicate names, whether this creates a draft or immediately deploys, what permissions are required, or any rate limits. With annotations covering safety profile, the description adds some value through the HTTP method but lacks richer behavioral disclosure.

  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 concise but poorly structured. It front-loads with '[compose] compose.create (POST)' which is somewhat useful, but then devolves into a bare parameter list without explanatory text. While not verbose, the structure doesn't effectively communicate purpose or usage, making it inefficient despite its brevity.

  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 (7 parameters, creation tool), zero schema description coverage, no output schema, and minimal annotations, the description is inadequate. It doesn't explain what gets created, what the expected outcome is, error conditions, or relationships between parameters. For a creation tool with multiple parameters in a complex system, this leaves too many gaps for effective agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for parameter meaning. While it lists parameter names and basic types, it provides almost no semantic information about what these parameters represent (e.g., what is 'environmentId', what does 'composeType' control, what format should 'composeFile' use). The description fails to compensate for the complete lack of schema descriptions, leaving 7 parameters with minimal guidance beyond their names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('compose.create') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being created (a Docker Compose application? a compose configuration?), nor does it distinguish this from sibling compose tools like dokploy_compose_deploy or dokploy_compose_update. The description fails to provide a clear verb+resource statement of purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. With many sibling tools in the compose category (create, delete, deploy, update, etc.), there's no indication of when this creation tool is appropriate versus other compose operations or versus application creation tools. No prerequisites, context, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_getConvertedComposeC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation. The description adds no behavioral context beyond this, such as what 'converted' entails, potential side effects, or response format. Since annotations cover the safety profile adequately, the description's minimal addition results in a baseline score.

  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 brief but not effectively structured. It includes the tool name, HTTP method, and a parameter list, but the information is minimal and lacks front-loaded clarity. While concise, it under-specifies rather than being efficiently informative, making it adequate but not well-organized.

  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 (involving 'conversion' of a compose), no output schema, and minimal annotations, the description is incomplete. It doesn't explain what 'converted' means, the output format, or any dependencies. For a tool with potential nuance in conversion processes, this leaves significant gaps for an agent to understand its full context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only indicates 'composeId' is a required string. The description lists the parameter but adds no semantic meaning—it doesn't explain what a composeId is, its format, or how it relates to conversion. With low schema coverage, the description fails to compensate, leaving the parameter poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and HTTP method ('compose.getConvertedCompose (GET)') without explaining what 'getConvertedCompose' means. It mentions a 'composeId' parameter but doesn't clarify what resource is being retrieved or what 'converted' refers to. This is borderline tautological as it provides minimal additional meaning 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for conversion, or related tools (e.g., other compose tools like dokploy_compose_one or dokploy_compose_processTemplate). Without usage context, an agent cannot determine when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_getTagsC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), which already inform the agent this is a safe, repeatable read operation. The description adds minimal behavioral context beyond annotations—it mentions the HTTP method (GET) and implies a parameter (baseUrl), but doesn't describe what 'tags' are, potential rate limits, authentication needs, or return format. With annotations covering safety, the bar is lower, but the description adds only basic operational details.

  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 brief and front-loaded with the tool name and method, but it's under-specified rather than concise. The two-line format is structured, but the content lacks substance—it doesn't earn its place with informative sentences. It avoids verbosity but sacrifices clarity, making it minimally adequate in length but not effective.

  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 (1 parameter, no output schema) and rich annotations, the description is incomplete. It doesn't explain what 'tags' are (e.g., Docker image tags for Compose services), the purpose of baseUrl, or the return value. Annotations handle safety, but the description leaves operational context vague, making it insufficient for an agent to understand the tool's full scope without external knowledge.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'baseUrl (string, optional)' as a parameter, but the input schema already defines this parameter with 0% description coverage (no schema description). The description doesn't add meaning beyond the schema—it doesn't explain what baseUrl is for (e.g., a Docker registry URL), its format, or default behavior. With low schema coverage, the description fails to compensate adequately, leaving the parameter poorly documented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[compose] compose.getTags (GET)' restates the tool name and HTTP method but doesn't specify what 'tags' refers to or what resource is being retrieved. It lacks a clear verb+resource statement like 'Retrieve Docker Compose tags' or similar. While it mentions 'compose' context, it's essentially a tautology of the name with minimal added value.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. The sibling tools list includes many compose-related tools (e.g., dokploy_compose_create, dokploy_compose_search, dokploy_compose_templates), but the description doesn't differentiate this tool from them or specify any prerequisites or typical use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_isolatedDeploymentC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key behavioral hints (readOnlyHint=true, destructiveHint=false, idempotentHint=false, openWorldHint=true), indicating a safe, non-destructive operation that may have side effects and supports open-world queries. The description adds no additional behavioral context beyond the POST method hint, such as what 'isolatedDeployment' entails or any rate limits, but it does not contradict the annotations.

  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 concise with two lines, but it is poorly structured: the first line is redundant with the name and title, and the parameter list is basic without context. While it avoids verbosity, it lacks front-loaded clarity, making it inefficient in conveying essential information quickly.

  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 implied by 'isolatedDeployment' and the lack of an output schema, the description is incomplete. It fails to explain what the tool does, its expected outcomes, or how it fits within the deployment workflow, leaving significant gaps despite the annotations covering safety aspects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameters ('composeId (string, required)' and 'suffix (string, optional)') but offers no semantic explanation—e.g., what a 'composeId' refers to or how 'suffix' affects the deployment. This minimal information partially compensates but falls short of fully clarifying parameter purposes.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description merely restates the tool name with minimal context ('[compose] compose.isolatedDeployment (POST)'), providing no specific verb or resource details. It does not explain what 'isolatedDeployment' means or how it differs from sibling compose tools like 'dokploy_compose_deploy' or 'dokploy_compose_deployTemplate', making it a tautology that adds little value 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 Guidelines1/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 lacks any mention of context, prerequisites, or exclusions, leaving the agent with no information to decide between this and other deployment-related tools in the sibling list, such as 'dokploy_compose_deploy' or 'dokploy_compose_redeploy'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_loadMountsByServiceC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds minimal behavioral context beyond what annotations provide. Annotations already declare this as read-only, non-destructive, idempotent, and open-world. The description only adds that it's a GET operation, which is implied by readOnlyHint=true. It doesn't describe response format, error conditions, rate limits, or authentication requirements that would be valuable for an agent.

  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 brief but inefficiently structured. It wastes space repeating the tool name and HTTP method while providing minimal useful information. The parameter listing is formatted but lacks explanatory value. While not verbose, it fails to front-load the most important information about what the tool actually accomplishes.

  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 2 parameters with 0% schema coverage, no output schema, and annotations that only cover safety properties, the description is inadequate. It doesn't explain what 'mounts' are in this context, what format the response takes, or how this tool relates to the broader compose/mounts functionality evident in sibling tools. For a tool that presumably returns structured data about service mounts, this leaves too many unknowns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It merely lists parameter names (composeId, serviceName) with types but provides no semantic meaning - what these IDs refer to, format expectations, or how they relate to each other. This leaves critical gaps for an agent to understand what values to provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('compose.loadMountsByService') without explaining what it actually does. It mentions 'GET' but doesn't specify what resource is being retrieved - mounts for a service in a compose configuration. This is essentially a tautology that provides minimal value beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention any sibling tools (like dokploy_mounts_listByServiceId or dokploy_compose_loadServices) that might be related, nor does it specify prerequisites, appropriate contexts, or limitations for using this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_loadServicesC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints (readOnly, non-destructive, idempotent, openWorld), so the description doesn't need to repeat safety information. However, it adds minimal behavioral context by specifying it's a GET operation, which aligns with readOnlyHint. No additional behavioral details (like rate limits, authentication needs, or what 'load' entails) are provided, but annotations cover the core safety profile adequately.

  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 brief and structured with a clear header and parameter list, but it's under-specified rather than concise. The first line repeats obvious information (tool name and HTTP method), and the parameter list lacks explanatory value. While not verbose, it fails to use its limited space effectively to clarify the tool's purpose.

  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 has 2 parameters with 0% schema coverage, no output schema, and annotations that cover safety but not operational context, the description is incomplete. It doesn't explain what 'services' are being loaded, the expected output format, or how the optional 'type' parameter affects behavior. For a tool with undocumented parameters and no output schema, more descriptive context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description lists parameters (composeId, type with enum values fetch/cache) but provides no semantic meaning—it doesn't explain what composeId refers to, what 'type' controls, or the difference between 'fetch' and 'cache' modes. This adds minimal value beyond the bare parameter names and enum values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('compose.loadServices') and HTTP method ('GET') without explaining what 'loadServices' means or what resource it operates on. It doesn't specify whether this loads service definitions, configurations, or statuses for a compose project. The purpose is vague and essentially tautological with the tool name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is absolutely no guidance on when to use this tool versus alternatives. With many sibling tools in the 'compose' category (like dokploy_compose_loadMountsByService, dokploy_compose_one, dokploy_compose_search), the description provides no context about when this specific loading operation is appropriate or what distinguishes it from other compose-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_randomizeComposeC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond that. It doesn't explain what 'randomize' entails (e.g., generating random values, shuffling settings), potential side effects, or error conditions. However, since annotations cover basic safety traits, the description meets a minimal bar without contradicting them.

  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 brief but not front-loaded with useful information; it starts with redundant details like '[compose]' and the HTTP method. The parameter list is minimal but lacks explanatory value. While concise, it under-specifies rather than being efficiently informative.

  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 implied by 'randomize' (likely a mutation with unspecified effects), 0% schema coverage, no output schema, and minimal annotations, the description is inadequate. It doesn't explain what the tool returns, how randomization works, or any constraints, leaving significant gaps for the agent to operate correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists parameter names ('composeId', 'suffix') without explaining their purpose. It doesn't clarify what 'composeId' refers to (e.g., an existing compose identifier) or what 'suffix' is used for (e.g., appending to randomized names). This leaves parameters largely undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('compose.randomizeCompose') and HTTP method ('POST') without explaining what 'randomizeCompose' means. It doesn't specify what resource is being randomized (e.g., a Docker Compose configuration) or what the effect is, making the purpose vague. The sibling tools include many compose-related operations, but this description fails to differentiate itself from them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context (e.g., after creating a compose), or exclusions. With many sibling tools like 'dokploy_compose_create', 'dokploy_compose_update', and 'dokploy_compose_deploy', the lack of usage guidelines leaves the agent guessing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_redeployC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide critical behavioral information: readOnlyHint=false (write operation), destructiveHint=false (non-destructive), idempotentHint=false (not idempotent), and openWorldHint=true (can create new resources). The description adds no behavioral context beyond what annotations already declare. It doesn't explain what 'redeploy' actually does (e.g., restarts containers, pulls new images, reapplies configurations), whether it causes downtime, or any side effects. With annotations covering the basic safety profile, a 3 is appropriate as the description adds no value.

  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 technically concise (three lines), but this conciseness comes at the cost of being under-specified. The structure includes the endpoint path and parameter list, which is organized, but the content lacks meaningful explanation. Every sentence (or line) should earn its place, and here the parameter listing without explanations doesn't add sufficient value.

  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 this is a write operation (readOnlyHint=false) with 3 parameters (0% schema coverage) and no output schema, the description is incomplete. It doesn't explain what redeployment entails, what the parameters mean, what happens during execution (e.g., downtime, logging), or what the response contains. For a mutation tool in a complex deployment system with many sibling tools, this leaves significant gaps for an AI agent to understand and use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 3 parameters have descriptions in the schema. The description only lists parameter names and types without explaining what they mean: 'composeId' (what identifies the compose to redeploy?), 'title' (what is this title used for?), 'description' (what is this description used for?). This provides minimal semantic value beyond the schema's type constraints, insufficient for a tool with 3 undocumented parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('compose.redeploy') without explaining what 'redeploy' means in this context. It doesn't specify what resource is being redeployed (a Docker Compose application/stack), what the redeployment entails, or how it differs from initial deployment. While it mentions the HTTP method (POST), this doesn't clarify the actual purpose 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., an existing compose deployment), when redeployment is appropriate (e.g., after configuration changes), or how it differs from similar tools like 'dokploy_compose_deploy' or 'dokploy_application_redeploy' in the sibling list. This leaves the agent with no context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_searchC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable search operation. The description adds no behavioral context beyond this, such as pagination behavior, rate limits, or authentication needs. Since annotations cover the safety profile adequately, the description meets the lower bar but adds minimal value.

  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 concise but poorly structured. It front-loads with '[compose] compose.search (GET)' which is redundant, followed by a parameter list that adds little value. While not verbose, the content does not earn its place effectively, leading to under-specification rather than clarity.

  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 (8 parameters, 0% schema coverage, no output schema), the description is incomplete. It lacks purpose, usage guidelines, parameter explanations, and behavioral details beyond annotations. For a search tool with multiple filtering options, this leaves the agent without sufficient context to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 by explaining parameter meanings. It only lists parameter names without any semantics, such as what 'q' searches for or how 'limit' and 'offset' control pagination. This fails to add value beyond the schema, leaving parameters undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description merely restates the tool name with '[compose] compose.search (GET)' and lists parameters without explaining what the tool actually does. It fails to specify the verb (search) and resource (compose applications) clearly, making it a tautology of the name/title. No distinction from sibling tools like 'dokploy_compose_one' or 'dokploy_compose_templates' is provided.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 any context, prerequisites, or exclusions. Given the many sibling tools (e.g., 'dokploy_compose_one' for fetching a single compose, 'dokploy_compose_templates' for templates), the lack of usage guidance is a significant gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_customRole_getStatementsC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description's burden is lower. The description doesn't add any behavioral context beyond what annotations already declare (e.g., no details about what 'statements' are, format of return data, or any constraints). However, it doesn't contradict the annotations, so it meets the minimum baseline with annotations present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While the description is extremely short, this is under-specification rather than effective conciseness. The single bracketed phrase '[customRole] customRole.getStatements (GET)' fails to convey meaningful information and doesn't front-load key details. It's not appropriately sized for a tool that likely returns data about custom role statements.

  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 likely purpose (retrieving statements for custom roles), the description is incomplete. There are no annotations about output format, no output schema, and the description doesn't explain what 'statements' are or what the return data looks like. While annotations cover safety aspects, the description fails to provide necessary context for effective use.

  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 0 parameters with 100% schema description coverage (empty schema). With no parameters, the description doesn't need to compensate for any gaps. The baseline for 0 parameters is 4, as there's nothing to explain beyond what the schema already indicates (no inputs required).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose1/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[customRole] customRole.getStatements (GET)' is a tautology that merely restates the tool name with minimal formatting. It doesn't specify what the tool actually does (e.g., what 'statements' are, what resource it operates on, or what 'get' means in this context). No meaningful purpose is communicated beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 provides no context about appropriate use cases, prerequisites, or relationships with sibling tools (like dokploy_customRole_all, dokploy_customRole_create, etc.). The agent receives zero usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_customRole_membersByRoleC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the agent knows this is a safe, repeatable read operation. The description adds minimal behavioral context by specifying it's a GET operation, but doesn't disclose important details like what format the members are returned in, whether there's pagination, or any authentication requirements beyond what annotations imply.

  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 brief but inefficiently structured. It wastes space repeating the tool name and includes a parameter listing that adds little value without context. While not verbose, it fails to front-load essential information about the tool's purpose.

  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?

  For a tool with 1 parameter (0% schema coverage), no output schema, and no sibling differentiation, the description is inadequate. It doesn't explain what 'members' are, what data structure is returned, or how this tool relates to other customRole operations. The annotations help with safety context, but the functional understanding remains incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description only lists 'roleName (string, required)' without explaining what this parameter represents, what valid values are, or how it's used. It doesn't compensate for the complete lack of schema descriptions, leaving the parameter's meaning unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('customRole.membersByRole') and HTTP method ('GET') without explaining what the tool actually does. It doesn't specify what resource is being retrieved (members of a custom role) or what 'members' refers to (users, groups, etc.). This is essentially a tautology that adds little beyond the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. The sibling list includes other customRole tools (all, create, getStatements, remove, update), but the description doesn't explain how this differs from them or when it's appropriate to retrieve members versus other role operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_deployment_removeDeploymentC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description does not disclose any behavioral traits beyond what the annotations provide. Annotations already indicate it is destructive (destructiveHint: true), non-idempotent (idempotentHint: false), and open-world (openWorldHint: true). The description adds no additional context about what 'removeDeployment' entails (e.g., whether it deletes associated resources, requires specific permissions, or has side effects). However, it does not contradict the annotations, so it meets the lower bar with annotations present.

  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 concise but poorly structured. It includes the tool name and HTTP method upfront, followed by a parameter list, but the formatting is minimal and lacks clear separation. While it avoids unnecessary verbosity, the information is presented in a way that is not optimally front-loaded or easy to parse, with some redundancy (e.g., repeating 'deployment').

  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 destructive nature (annotations: destructiveHint: true) and lack of output schema, the description is incomplete. It does not explain the consequences of removal, potential errors, or what happens to associated resources. For a destructive operation with one parameter, the description should provide more context to ensure safe and correct usage, but it falls short.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists the parameter 'deploymentId' but provides no semantic meaning beyond what the schema indicates (string, required). With schema description coverage at 0%, the description does not compensate by explaining what a deploymentId is, its format, or where to obtain it. This leaves the parameter poorly understood, failing to add meaningful value over the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name and HTTP method ('deployment.removeDeployment (POST)') but lacks a clear, specific purpose statement. It does not explicitly state what the tool does (e.g., 'deletes a deployment' or 'removes a deployment from the system'), and it does not differentiate from sibling tools like 'dokploy_deployment_killProcess' or 'dokploy_application_delete'. The description is tautological, essentially restating 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions for use, or any sibling tools that might be relevant (e.g., 'dokploy_deployment_killProcess' for stopping a process vs. removing a deployment). There is no explicit or implied context for usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_destination_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide important behavioral information (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds no behavioral context beyond what's already in annotations - it doesn't mention authentication requirements, rate limits, side effects, or what happens when updating specific fields. However, it doesn't contradict the annotations either, so it meets the baseline expectation when annotations are present.

  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 reasonably concise but poorly structured. It front-loads the tool name and method, but then presents a bulleted parameter list that belongs in the schema. The formatting as a code-like block makes it less readable. While not verbose, it wastes space on information that should be in structured fields rather than providing meaningful descriptive content.

  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?

  For a tool with 9 parameters, 0% schema description coverage, no output schema, and annotations that only cover basic behavioral hints, the description is severely inadequate. It doesn't explain what a 'destination' is in this system, what fields can be updated, what the update operation actually does, or what the expected response looks like. The agent would struggle to use this tool effectively without significant trial and error.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 9 parameters (8 required), the description merely lists parameter names without any semantic explanation. It doesn't clarify what 'provider' type 'any' means, what 'destinationId' identifies, what format 'endpoint' should follow, or the relationship between parameters. The description fails to compensate for the complete lack of schema descriptions, leaving parameters largely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('destination.update') with minimal added value. It mentions 'POST' which indicates the HTTP method, but doesn't explain what a 'destination' represents in this context or what specific aspects are being updated. While it lists parameters, it doesn't articulate the tool's purpose beyond the obvious from 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is absolutely no guidance about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or distinguish this from sibling tools like 'dokploy_destination_create' or 'dokploy_destination_remove'. An agent would have no contextual information about when this update operation is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_docker_getServiceContainersByAppNameC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation. The description adds minimal behavioral context by specifying 'GET', which aligns with read-only, but does not disclose additional traits like rate limits, authentication needs, or what 'service containers' entail. No contradiction with annotations exists, but the description adds little value beyond them.

  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 concise with two lines, but it's poorly structured: the first line is tautological, and the second merely lists parameters without context. While not verbose, it lacks front-loaded clarity and wastes space on redundant information. It could be more efficient by integrating purpose and parameters into a cohesive sentence.

  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 (2 parameters, 0% schema coverage, no output schema), the description is incomplete. It fails to explain the return value (e.g., what 'service containers' are), how results are formatted, or any error conditions. With annotations covering safety but no output schema, the description should provide more context to guide the agent effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters ('appName (string, required)' and 'serverId (string, optional)') but adds no semantic meaning—it doesn't explain what 'appName' refers to (e.g., application identifier), what 'serverId' is for, or how they affect the output. This partial listing compensates slightly but falls short of fully explaining parameter purposes.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name with minimal additional context ('[docker] docker.getServiceContainersByAppName (GET)'), which is essentially tautological. It mentions 'docker' and 'GET' but lacks a clear, specific verb-resource statement explaining what the tool actually does (e.g., retrieves containers for a service based on an app name). While it hints at a read operation, it doesn't distinguish from sibling tools like 'dokploy_docker_getContainers' or 'dokploy_docker_getContainersByAppLabel'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or exclusions, nor does it reference sibling tools for comparison. This leaves the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_domain_byComposeIdC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide comprehensive behavioral hints (readOnly, non-destructive, idempotent, openWorld), which already tell the agent this is a safe, repeatable lookup operation. The description adds minimal value beyond the 'GET' method indication, but doesn't contradict the annotations. It doesn't provide additional behavioral context like rate limits, authentication requirements, or what specific domain information is returned.

  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 extremely brief but not particularly well-structured. It includes the tool name, HTTP method, and parameter listing in a minimal format. While concise, it lacks proper front-loading of purpose and reads more like a technical signature than a helpful description. The information is presented but not optimally organized for understanding.

  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?

  For a tool with no output schema and minimal annotations beyond basic hints, the description is inadequate. It doesn't explain what domain information is returned, what format the response has, or how this tool relates to other domain tools. Given the complexity implied by the sibling tools list and the lack of output documentation, the description leaves significant gaps in understanding the tool's full context and usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and only one parameter (composeId), the description provides no semantic information about what composeId represents, what format it should have, or where to obtain it. The schema only indicates it's a required string with minimum length 1, but the description doesn't add any meaning beyond repeating the parameter name.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('domain.byComposeId') without clarifying what it actually does. It mentions 'GET' which implies retrieval, but doesn't specify what resource is retrieved (e.g., 'retrieve domain information for a compose'). This is essentially tautological - it repeats the name without adding meaningful purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. Given the sibling tools include dokploy_domain_byApplicationId, dokploy_domain_one, and other domain-related tools, the description provides no differentiation or context about when this specific composeId-based lookup is appropriate versus other domain lookup methods.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_domain_canGenerateTraefikMeDomainsC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already convey this is a safe, read-only, idempotent operation. The description adds minimal value by indicating it's a GET request, but doesn't disclose any behavioral traits beyond what annotations provide, such as what 'canGenerate' means in practice or what the response format might be.

  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 concise but poorly structured. It includes the tool name, HTTP method, and parameter listing in a single block. While brief, it lacks clear organization and front-loading of essential information - the purpose should come first, not be buried in the name repetition.

  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 domain management tools and 0% schema description coverage with no output schema, the description is inadequate. It doesn't explain what the tool returns (boolean, object, list), what 'TraefikMeDomains' means, or how this fits into the broader domain workflow. The annotations help but don't compensate for the missing functional explanation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. The description lists 'serverId (string, required)' but provides no semantic meaning - what a serverId is, where to get it, format expectations, or how it relates to domain generation capability. This adds little value beyond what the bare schema already indicates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name '[domain] domain.canGenerateTraefikMeDomains (GET)' which is essentially a tautology of the tool name. It doesn't explain what the tool actually does - whether it checks capability, returns a boolean, or performs some validation. The verb 'canGenerate' is ambiguous without context about what 'TraefikMeDomains' refers to.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. There are multiple domain-related sibling tools (dokploy_domain_generateDomain, dokploy_domain_validateDomain, dokploy_domain_byApplicationId, etc.), but the description offers no differentiation or context about when this specific tool should be invoked.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_domain_generateDomainC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable operation (readOnlyHint=false), non-destructive, non-idempotent, and open-world. The description adds no behavioral context beyond what annotations provide - no mention of what 'generate' entails, whether it creates resources, requires permissions, or has side effects. With annotations covering basic safety, the description adds minimal value.

  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 brief but poorly structured - it starts with redundant bracketed information '[domain] domain.generateDomain (POST)' before listing parameters. While concise, it wastes space on obvious information (POST method) rather than explaining purpose. The parameter list format is clear but adds little value.

  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?

  For a domain generation tool with 2 parameters (0% schema coverage), no output schema, and annotations only covering basic hints, the description is inadequate. It doesn't explain what the tool returns, what 'generating a domain' means operationally, or how parameters affect the outcome. The agent would struggle to use this correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides only type information. The description lists parameter names but adds no semantic meaning - doesn't explain what 'appName' refers to (application identifier? name pattern?), what 'serverId' is for, or how they affect domain generation. This fails to compensate for the schema's lack of descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('domain.generateDomain') without explaining what 'generateDomain' means in this context. It mentions parameters but doesn't specify what the tool actually does (e.g., creates a domain, generates a subdomain, provisions DNS). This is closer to tautology than clear purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 versus alternatives. There are sibling domain tools (create, delete, update, validate) but the description doesn't explain how this differs from 'dokploy_domain_create' or when generation is appropriate versus creation. No prerequisites or context are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_domain_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (accepts unknown values). The description adds no behavioral context beyond what annotations already declare. It doesn't explain what gets updated, whether permissions are required, rate limits, or what happens on success/failure. With annotations covering the basic safety profile, this earns a baseline 3.

  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 technically concise - just a method signature and parameter list. However, it's structured poorly as a parameter dump rather than a helpful description. While not verbose, it wastes its limited space on information already available in the schema rather than adding explanatory value. The front-loaded content is unhelpful ('[domain] domain.update (POST)').

  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 (11 parameters, mutation operation, no output schema), the description is severely incomplete. It doesn't explain what a 'domain' represents in this system, what the update affects, what the expected outcome is, or how to interpret parameters. With no output schema and 0% parameter documentation coverage, the description should provide much more context to help an agent use this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 11 parameters have descriptions in the schema. The description merely lists parameter names and basic types without explaining what they mean, how they interact, or what values are appropriate. For example, it doesn't explain what 'certificateType' controls, what 'domainId' refers to, or how 'host' relates to the domain being updated. This fails to compensate for the complete lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology - it restates the tool name 'domain.update' and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being updated (a domain configuration), what system it operates in, or what the update entails. The description fails to provide meaningful purpose beyond what's already in 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There are no usage guidelines whatsoever. The description doesn't indicate when to use this tool, what prerequisites exist, or how it differs from sibling tools like 'dokploy_domain_create', 'dokploy_domain_delete', or 'dokploy_domain_validateDomain'. An agent would have no guidance on when this update operation is appropriate versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_domain_validateDomainC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate read-only, non-destructive, non-idempotent, and open-world behavior, which the description does not contradict. However, it adds minimal context beyond annotations, such as the HTTP method (POST) and parameter roles, but lacks details on validation criteria, error conditions, or rate limits. With annotations covering safety, this is adequate but not rich.

  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 brief and front-loaded with the tool name and HTTP method, but includes redundant parameter details that are already in the schema. While not verbose, it could be more efficient by focusing on added value rather than repeating schema information.

  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 domain validation, lack of output schema, and 0% schema description coverage, the description is insufficient. It fails to explain what validation checks are performed, what the output indicates, or how to interpret results, leaving significant gaps for the agent to understand tool behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters ('domain' and 'serverIp') with types and required status, but provides no semantic meaning, such as what constitutes a valid domain or how serverIp affects validation. This adds little value beyond the schema's structural information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('domain.validateDomain') and lists parameters without explaining what validation entails. It lacks a specific verb-resource combination and doesn't distinguish from sibling tools like 'dokploy_domain_create' or 'dokploy_domain_update', making the purpose vague 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_environment_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal value by indicating 'GET', which aligns with read-only behavior, but does not disclose additional traits like rate limits, authentication needs, or response format. No contradiction with annotations exists.

  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 concise with two lines, but it is under-specified rather than efficiently informative. The first line is vague, and the parameter listing is minimal. While not verbose, it lacks essential details, making it less helpful despite its brevity.

  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 (a read operation with one required parameter), annotations cover safety, but the description lacks purpose clarity, usage guidelines, and parameter semantics. With no output schema and low schema coverage, the description is incomplete, failing to provide sufficient context for effective tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'environmentId (string, required)' but does not explain what this parameter represents (e.g., an ID format, source, or example). This adds only basic structural information without meaningful semantics, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[environment] environment.one (GET)' is vague and tautological. It restates the tool name 'environment_one' with minimal context ('environment' and 'GET'), but does not specify what the tool actually does (e.g., retrieve details of a specific environment). It lacks a clear verb-resource combination and does not distinguish from siblings like 'dokploy_environment_search' or 'dokploy_environment_byProjectId'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios compared to other environment-related tools in the sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_environment_searchC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which tell the agent this is a safe, repeatable search operation. The description adds no behavioral context beyond what annotations already declare (e.g., no rate limits, pagination behavior, or authentication requirements). However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  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 brief and structured with a parameter list, but it's under-specified rather than concise. The first line '[environment] environment.search (GET)' is redundant with the tool name, and the parameter list lacks explanatory value. It's front-loaded with the API signature but wastes space on obvious details.

  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?

  For a search tool with 6 parameters, 0% schema description coverage, no output schema, and rich annotations, the description is insufficient. It doesn't explain what the tool returns (e.g., list of environments), how results are ordered, or error conditions. The annotations cover safety, but the description fails to provide necessary operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types but adds no semantic meaning (e.g., what 'q' searches for, how 'limit' and 'offset' work for pagination, what 'projectId' filters). This minimal listing doesn't adequately compensate for the complete lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('environment.search') and lists parameters but doesn't explain what the tool actually does. It lacks a clear verb-resource statement like 'search for environments' and doesn't distinguish this search tool from other environment-related tools (create, update, duplicate, remove, one, byProjectId) in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention when to use search versus 'dokploy_environment_one' (get one environment) or 'dokploy_environment_byProjectId' (list by project), nor does it provide any context about prerequisites or typical use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_environment_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which tell the agent this is a non-destructive, idempotent mutation that may accept unknown parameters. The description adds no behavioral context beyond what annotations already declare. It doesn't mention what happens when fields are updated (e.g., whether changes are immediate, require redeployment, or affect running services), nor any permission requirements, rate limits, or error conditions. With annotations covering the basic safety profile, the description adds minimal value.

  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 brief but poorly structured. It starts with a tautological line '[environment] environment.update (POST)' followed by a parameter list. While concise, it wastes the opening line on redundant information. The parameter list is formatted but lacks explanatory value. It's front-loaded with unhelpful content rather than purpose or usage.

  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?

  This is a mutation tool (update) with 5 parameters, 0% schema description coverage, no output schema, and rich annotations. The description fails to compensate for the missing parameter semantics, provides no behavioral context beyond annotations, and offers no guidance on usage. For an environment update operation in a complex deployment system, the description leaves critical gaps about what can be updated, how updates propagate, and what the tool returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types but adds no semantic meaning. It doesn't explain what environmentId identifies, what name/description fields represent, what projectId does (changes project association?), or what env contains (environment variables? configuration?). For a tool with 5 parameters and 0% schema coverage, this minimal listing is inadequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'environment.update (POST)' which is a tautology of the tool name and HTTP method, and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being updated (environment settings, configuration, etc.) or what the update operation entails. The sibling tools include dokploy_environment_create, dokploy_environment_remove, and dokploy_environment_duplicate, but this description doesn't differentiate from them beyond the basic verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling environment tools (create, duplicate, remove, search, byProjectId, one) but no indication of when this update tool is appropriate versus creating a new environment or using other environment operations. No prerequisites, constraints, or use cases are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitea_getGiteaUrlC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation. The description adds no behavioral context beyond this, such as what the URL represents, any rate limits, or authentication needs. Since annotations cover the safety profile, the description doesn't contradict them but adds minimal value, warranting a baseline score.

  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 brief but poorly structured—it includes redundant information (tool name and HTTP method) and a parameter list without explanation. While not verbose, it lacks effective front-loading of useful information, making it inefficient rather than concise.

  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 has one parameter with 0% schema coverage, no output schema, and annotations that only cover safety, the description is incomplete. It doesn't explain what the tool returns (e.g., a URL string or object) or the context of use, leaving significant gaps for an AI agent to understand and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only defines giteaId as a required string. The description lists the parameter but adds no semantics—it doesn't explain what giteaId is (e.g., an identifier for a Gitea provider or instance), its format, or where to obtain it. This fails to compensate for the low schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and HTTP method ('[gitea] gitea.getGiteaUrl (GET)'), which is tautological. It doesn't specify what the tool actually does—whether it retrieves a URL for a Gitea instance, configuration, or something else. While it mentions 'Parameters' with giteaId, this doesn't clarify the purpose 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 Guidelines1/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 sibling tools list includes other Gitea-related tools (e.g., dokploy_gitea_getGiteaBranches, dokploy_gitea_getGiteaRepositories), but the description doesn't differentiate this tool from them or specify any context for its use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_github_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds minimal behavioral context beyond what annotations provide. Annotations clearly indicate this is a read-only, non-destructive, idempotent, open-world operation. The description adds only that this is a GET operation, which is consistent with readOnlyHint=true. However, it doesn't provide any additional behavioral details like what specific GitHub data is retrieved, authentication requirements, rate limits, or response format.

  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 extremely concise - just two lines with parameter information. While brief, it's not particularly well-structured or front-loaded with the most important information. The '[github] github.one (GET)' format is somewhat cryptic, and the parameter documentation is minimal. It avoids unnecessary verbosity but sacrifices clarity for brevity.

  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 single parameter, 0% schema coverage, no output schema, and rich annotations, the description is incomplete. While annotations cover safety aspects, the description fails to explain what the tool actually returns (GitHub provider configuration? repository details?), what the githubId parameter means, or how this tool differs from other GitHub tools. For a tool with no output schema, some indication of return values would be helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for parameter documentation. It only lists 'githubId (string, required)' without explaining what a githubId represents (GitHub user ID, repository ID, organization ID?), what format it expects, or where to obtain it. This leaves the single required parameter poorly defined despite the description attempting to document it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[github] github.one (GET)' which is a tautology - it essentially repeats the tool name and adds HTTP method information. It doesn't explain what the tool actually does (retrieve GitHub provider information, fetch GitHub repository data, etc.). While it mentions 'github' as a resource, the specific action and purpose remain unclear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool versus other GitHub-related tools (like dokploy_github_getGithubBranches, dokploy_github_getGithubRepositories, dokploy_github_githubProviders, etc.), nor does it mention any prerequisites, context, or alternatives. The agent receives zero guidance on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_github_testConnectionC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds no behavioral details beyond this, such as what 'testConnection' entails (e.g., network check, auth validation), expected outcomes, or error handling. With annotations covering basic hints, the description adds minimal value but doesn't contradict them.

  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 brief but inefficiently structured. It includes redundant information like '(POST)' and a parameter list that adds little value. While not verbose, it lacks front-loaded clarity and wastes space on formatting rather than informative content.

  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 (a connection-testing operation with one parameter), the description is incomplete. No output schema exists, and the description doesn't explain what the tool returns (e.g., success/failure status, error details). With annotations providing some hints but no output details, the description leaves significant gaps for the agent to understand the tool's full behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'githubId (string, required)' without explaining what a githubId is (e.g., an identifier for a GitHub provider configuration, a user ID, or something else). It fails to add meaningful context beyond the schema's type and requirement, leaving the parameter's purpose unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[github] github.testConnection (POST)' restates the tool name and HTTP method but doesn't specify what 'testConnection' means. It doesn't clarify whether this tests GitHub API connectivity, authentication, or something else. While it mentions 'github' context, the purpose remains vague compared to the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 is provided. It doesn't mention prerequisites (e.g., needing a configured GitHub provider), alternatives (e.g., other testConnection tools for different providers like bitbucket_testConnection), or typical use cases. The agent must infer usage from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitlab_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds minimal behavioral context beyond what annotations provide. Annotations indicate this is a non-readonly, non-destructive, non-idempotent operation with open-world semantics. The description only adds that it's a POST operation (implied creation). It doesn't describe authentication requirements, rate limits, side effects, or what happens on success/failure. However, it doesn't contradict the annotations, so it gets a baseline score for adding some minimal context.

  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 technically concise but under-specified rather than efficiently informative. It wastes space on formatting (brackets, parentheses) and redundant information (listing all parameters that are already in the schema). The structure is poor - it starts with redundant '[gitlab] gitlab.create (POST)' instead of a clear purpose statement. However, it's not excessively 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 the complexity (9 parameters, creation operation), lack of output schema, and minimal annotations, the description is inadequate. It doesn't explain what the tool returns, what GitLab entity is created, prerequisites, or error conditions. For a creation tool with many parameters and no output schema, this leaves significant gaps in understanding how to use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 9 parameters (3 required), the description provides only a bare list of parameter names and types without any semantic meaning. It doesn't explain what 'authId', 'gitlabUrl', 'gitlabInternalUrl', or other parameters represent, their expected formats, or relationships between them. The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is a tautology that essentially restates the tool name ('gitlab.create') without explaining what it actually creates. It provides no meaningful verb+resource combination or specific purpose statement. While it mentions 'POST' which implies a creation operation, it doesn't specify what GitLab entity is being created (provider configuration, integration, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance about when to use this tool versus alternatives. There are multiple GitLab-related sibling tools (dokploy_gitlab_gitlabProviders, dokploy_gitlab_update, dokploy_gitlab_testConnection, etc.), but the description offers no differentiation or context about when this specific creation tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitlab_getGitlabBranchesC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), indicating this is a safe, repeatable read operation. The description adds minimal context by specifying 'GET', which aligns with read-only behavior, but does not disclose additional traits like rate limits, authentication needs, pagination, or what 'openWorldHint' implies (e.g., may return varying data). With annotations covering core safety, the description adds limited value beyond them.

  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 brief and front-loaded with the tool name and HTTP method, but it wastes space by repeating the name and listing parameters without explanation. The parameter list adds no value beyond the schema, making the description inefficient. However, it avoids excessive verbosity, keeping to essential but unhelpful elements.

  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 4 parameters with 0% schema coverage, no output schema, and annotations that cover safety but not operational details, the description is incomplete. It does not explain what the tool returns (e.g., list of branch names/objects), how parameters interact (e.g., 'id' vs 'gitlabId'), or error conditions. For a read operation with undocumented parameters, more context is needed for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description lists parameters ('id', 'owner', 'repo', 'gitlabId') but does not explain their semantics (e.g., 'owner' is the GitLab username/group, 'repo' is the repository name, 'gitlabId' might be a project ID). It fails to compensate for the schema gap, leaving parameters largely meaningless to an agent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('gitlab.getGitlabBranches') and adds the HTTP method 'GET', but does not clearly articulate what the tool does. It lacks a specific verb-resource combination (e.g., 'retrieve branches from a GitLab repository') and does not distinguish itself from sibling tools like 'dokploy_gitlab_getGitlabRepositories' or other Git provider branch tools (e.g., 'dokploy_github_getGithubBranches'). This is closer to a tautology than a clear purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools (e.g., 'dokploy_gitlab_getGitlabRepositories' for repositories, or other Git provider branch tools), nor does it specify prerequisites, context (e.g., after setting up a GitLab provider), or any exclusions. This leaves the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitlab_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (accepts unknown parameters). The description adds no behavioral context beyond these annotations—it doesn't explain what 'update' means operationally, whether it requires specific permissions, what happens on success/failure, or any rate limits. However, it doesn't contradict the annotations, so it meets the lower bar with annotations present but adds minimal value.

  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 brief but poorly structured—it's essentially a parameter list formatted as text rather than a coherent explanation. While not verbose, it wastes space on redundant information (parameter names already in schema) instead of providing meaningful content. The structure doesn't front-load key information about the tool's purpose.

  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 9 parameters with 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is severely incomplete. It doesn't explain what the tool updates, what the parameters mean, what the expected outcome is, or how it fits into the broader system (e.g., Dokploy's GitLab integration). For a mutation tool with many parameters, this leaves critical gaps for an agent to understand and use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 9 parameters have descriptions in the schema. The description merely lists parameter names and types without explaining their purpose (e.g., what 'gitlabId' represents, what 'gitlabInternalUrl' is for, or how 'secret' is used). This fails to compensate for the lack of schema documentation, leaving parameters semantically unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('gitlab.update') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being updated (e.g., a GitLab provider configuration) or what the update operation entails. This is essentially a tautology that provides no meaningful purpose statement beyond what's in 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 Guidelines1/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 doesn't mention prerequisites, when this update should be performed, or how it relates to sibling tools like 'dokploy_gitlab_create' or 'dokploy_gitlab_one'. Without any usage context, an agent cannot determine appropriate invocation scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_licenseKey_updateEnterpriseSettingsC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key hints: readOnlyHint=false (mutation), destructiveHint=false (safe), idempotentHint=true (repeatable), openWorldHint=true (flexible). The description adds that it's a POST operation, implying an update action, but doesn't disclose behavioral details beyond annotations, such as what 'enterprise features' entail, potential side effects, or authentication needs. With annotations covering core traits, the description adds minimal context, warranting a baseline score.

  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 brief but not optimally structured. It includes the tool path and HTTP method upfront, followed by a parameter list, which is clear but could be more informative. It avoids redundancy but under-specifies purpose and context, making it somewhat sparse rather than concise.

  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 updates license settings (a mutation with potential system impact), annotations help but the description lacks critical context: no output schema exists, so return values are undocumented; it doesn't explain what enterprise features are or their implications; and sibling tools include related license key operations without differentiation. For a mutation tool with no output schema, this is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'enableEnterpriseFeatures' as a boolean optional parameter, which adds basic semantics (what the parameter controls). However, it doesn't explain what enabling/disabling does, default behavior if omitted, or any constraints (e.g., requires admin rights). With one parameter and low schema coverage, this partial info is insufficient for full understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name with minimal elaboration ('licenseKey.updateEnterpriseSettings'), which is tautological. It specifies the HTTP method (POST) and lists a parameter, but doesn't clearly articulate what the tool actually does (e.g., enabling/disabling enterprise features for a license key). The purpose is vague 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 Guidelines1/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. It doesn't mention prerequisites (e.g., needing a valid license key), related tools like 'dokploy_licenseKey_getEnterpriseSettings' for checking current settings, or any context for when enterprise features should be enabled/disabled. The agent receives no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_changeStatusC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is not read-only, not destructive, not idempotent, and open-world, but the description adds no behavioral context beyond this. It does not explain what 'changeStatus' entails (e.g., whether it triggers restarts, affects data, or has side effects), leaving gaps despite annotations covering basic safety. No contradiction with annotations is present.

  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 brief but inefficiently structured, repeating information from the schema without adding context. It uses a parameter list format that duplicates schema details, wasting space that could be used for explanatory content. However, it is not overly verbose, keeping to essential but unhelpful elements.

  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 (mutating database status), lack of output schema, and low schema description coverage, the description is incomplete. It fails to explain the tool's purpose, usage, parameter meanings, or behavioral outcomes, leaving the agent with insufficient information to use it correctly despite annotations providing some safety hints.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists parameter names and types without explaining their meaning. For example, it does not clarify what 'mariadbId' refers to (e.g., a database instance ID) or the implications of 'applicationStatus' values (e.g., what 'idle' vs 'running' means). This adds minimal value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title without adding meaningful clarification. It mentions 'mariadb.changeStatus (POST)' which echoes the name/title, and lists parameters that are already defined in the schema. It does not specify what 'changeStatus' actually does (e.g., update the operational state of a MariaDB instance), making it vague and tautological.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. Sibling tools include dokploy_mariadb_start, dokploy_mariadb_stop, and dokploy_mariadb_update, which likely relate to MariaDB management, but the description does not differentiate this tool from them or provide any context for its application.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these annotations (it doesn't claim read-only or idempotent behavior). However, it adds minimal behavioral context beyond what annotations provide - only the HTTP method 'POST' is mentioned. For a creation tool with 10 parameters, more behavioral details (like what happens on duplicate names, whether it triggers deployment, or authentication requirements) would be helpful.

  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 technically concise (just two lines plus a parameter list), but this conciseness comes at the cost of being under-specified. The structure with a parameter list is organized, but the core description '[mariadb] mariadb.create (POST)' is inadequate. Every sentence should earn its place, and the parameter list without explanations doesn't add sufficient value.

  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?

  For a complex database creation tool with 10 parameters, no output schema, and 0% schema description coverage, the description is severely incomplete. It doesn't explain what gets created (a database instance? container? service?), what the return value might be, error conditions, or how this integrates with the broader Dokploy system. The annotations provide some behavioral hints, but the description fails to compensate for the significant documentation gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description carries full burden for explaining parameters. While it lists all 10 parameters with basic types, it provides no semantic meaning - no explanation of what 'environmentId' refers to, what format 'databasePassword' requires, what 'serverId' represents, or how 'dockerImage' affects the created database. The parameter list adds little value beyond what's already visible in the schema structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('mariadb.create') without explaining what it actually does. While it mentions 'POST' and lists parameters, it doesn't state the specific action (e.g., 'Creates a new MariaDB database instance in Dokploy'). The description fails to distinguish this from sibling tools like 'dokploy_mariadb_update' or 'dokploy_mysql_create'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing environment), when not to use it, or what other tools might be relevant (like 'dokploy_mariadb_deploy' or 'dokploy_mariadb_update'). The agent receives no contextual usage information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_deployC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond the name 'deploy'. It does not explain what 'deploy' does (e.g., starts a database, applies configurations, or initiates a container), potential side effects, authentication needs, or rate limits. With annotations covering basic hints, the description adds minimal value, scoring a baseline 3.

  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 brief but inefficiently structured, repeating the tool name and including a parameter list that adds little value without context. It is front-loaded with '[mariadb] mariadb.deploy (POST)', but the subsequent parameter line is under-specified. While not verbose, it lacks meaningful content, making it mediocre in conciseness.

  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 a deployment tool with no output schema, annotations provide basic hints but the description fails to explain what the tool does, its parameters, or expected outcomes. Sibling tools suggest this is part of a MariaDB management suite, but the description does not integrate this context. It is incomplete for guiding an agent in tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'mariadbId' as a required parameter without explaining its meaning (e.g., an ID of an existing MariaDB resource to deploy). It does not clarify format, source, or constraints. With one undocumented parameter and no compensation in the description, this falls below the baseline of 3 for low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('mariadb.deploy') without adding meaningful context about what 'deploy' entails. It does not specify what resource is being deployed (e.g., a MariaDB database instance, container, or configuration) or distinguish it from sibling tools like 'dokploy_mariadb_create' or 'dokploy_mariadb_start', which also involve MariaDB operations. This is a tautology rather than a clear purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., whether a MariaDB resource must already exist via 'dokploy_mariadb_create'), differentiate from similar tools like 'dokploy_mariadb_start' or 'dokploy_mariadb_redeploy', or specify any context for deployment. This leaves the agent with no usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description doesn't need to repeat these. However, the description adds minimal behavioral context beyond 'GET' - it doesn't specify what data is returned, whether authentication is required, or any rate limits. With good annotation coverage, a baseline score of 3 is appropriate as the description adds little value beyond what annotations already declare.

  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 extremely concise but borders on under-specification. The two-line format with 'Parameters:' section is structured, but the content is insufficient. While there's no wasted text, the brevity comes at the cost of clarity - every sentence should earn its place, but here the sentences don't provide enough value.

  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 apparent purpose (retrieving MariaDB information by ID), the description is incomplete. There's no output schema, and the description doesn't explain what data is returned. While annotations cover safety aspects, the description fails to provide necessary context about the tool's function, parameter meaning, or relationship to sibling tools. For a tool that likely returns database configuration or status information, this is inadequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the parameter 'mariadbId' has no documentation in the schema. The description provides no additional semantic information about this parameter - what format it expects, where to obtain valid IDs, or what constitutes a valid MariaDB identifier. With 1 parameter and 0% schema coverage, the description fails to compensate for the documentation gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[mariadb] mariadb.one (GET)' which is tautological - it essentially restates the tool name with minimal clarification. It doesn't specify what action is performed (retrieve details? fetch configuration?) or what resource is accessed. While 'GET' implies a read operation, the purpose remains vague compared to the specificity needed for effective tool selection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'dokploy_mariadb_search', 'dokploy_mariadb_create', and 'dokploy_mariadb_update', there's no indication whether this tool retrieves a single MariaDB instance by ID, gets configuration details, or serves some other specific purpose that differs from search operations. The agent receives no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_removeC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, which already inform the agent that this is a non-idempotent, destructive write operation. The description adds no behavioral context beyond what annotations provide, such as what 'remove' entails (e.g., data deletion, resource cleanup, or irreversible effects). However, it does not contradict the annotations, so it meets the lower bar with annotations present.

  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 concise but under-specified, consisting of a brief header and a parameter list. It is front-loaded with the tool name and method, but the parameter section adds little value due to lack of semantics. While not verbose, it misses opportunities to convey essential information efficiently.

  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 destructive nature (annotations indicate destructiveHint=true), no output schema, and low schema description coverage (0%), the description is insufficient. It does not explain the consequences of removal, potential side effects, or what to expect upon success/failure, making it inadequate for safe and effective use by an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'mariadbId (string, required)' without explaining what this parameter represents (e.g., an ID of a MariaDB instance, database name, or deployment identifier). It fails to compensate for the lack of schema descriptions, leaving the parameter's meaning unclear beyond its type and requirement.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[mariadb] mariadb.remove (POST)' is essentially a tautology that restates the tool name with minimal additional information. It indicates the resource (mariadb) and action (remove), but lacks specificity about what exactly is being removed (e.g., a MariaDB database instance, configuration, or deployment) and provides no meaningful differentiation from sibling tools like 'dokploy_mariadb_delete' or other 'remove' tools in the list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions for use, or any sibling tools that might be relevant (e.g., 'dokploy_mariadb_delete' or other database removal tools). This leaves the agent with no context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_saveExternalPortC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond that. It doesn't explain what 'saveExternalPort' entails (e.g., whether it restarts services, affects connectivity, has side effects). While annotations cover basic traits, the description fails to disclose operational details like rate limits, authentication needs, or error conditions, offering minimal value beyond the structured data.

  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 brief but inefficiently structured: it repeats the tool name and HTTP method without adding value, and the parameter list is redundant with the schema. While not verbose, it wastes space on unhelpful details instead of being front-loaded with actionable information. It could be more concise by omitting the repetitive elements and focusing on purpose.

  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 a database configuration tool with no output schema and 0% schema description coverage, the description is inadequate. It lacks details on what the tool does, when to use it, parameter meanings, expected outcomes, or error handling. Annotations provide some behavioral hints, but the description doesn't fill the gaps, making it incomplete for effective agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameters (mariadbId, externalPort) but adds no semantics—no explanation of what mariadbId refers to (e.g., database instance ID), what externalPort means (e.g., port number or null to disable), or format constraints. This leaves parameters largely undocumented, failing to compensate for the low schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name with minimal context ('[mariadb] mariadb.saveExternalPort (POST)'), which is essentially tautological. It doesn't specify what 'saveExternalPort' actually does (e.g., configure network access, map ports, update settings) or differentiate it from sibling tools like dokploy_mongo_saveExternalPort or dokploy_mysql_saveExternalPort. The purpose remains vague beyond the literal name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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, prerequisites, or context. It doesn't mention related tools (e.g., dokploy_mariadb_create, dokploy_mariadb_update) or scenarios (e.g., after deployment, for external access). The description provides zero usage instructions, leaving the agent to guess based on the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mongo_changeStatusC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable operation (readOnlyHint=false) that's non-destructive and non-idempotent. The description doesn't add any behavioral context beyond what annotations already provide - it doesn't explain what 'changing status' entails, whether it affects running services, what permissions are required, or what the response looks like. However, it doesn't contradict the annotations either.

  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 brief but inefficiently structured. It wastes characters on redundant information like '[mongo]' and 'POST' while failing to convey essential purpose. The parameter listing format is somewhat organized but doesn't add value beyond the schema. While concise, it's not effectively structured for comprehension.

  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?

  For a mutation tool with 2 parameters, 0% schema description coverage, no output schema, and annotations that only cover basic safety hints, this description is inadequate. It doesn't explain what the tool does, when to use it, what the parameters mean, what happens when invoked, or what to expect in return. The description fails to compensate for the sparse structured data.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It merely lists parameter names and types without explaining what 'mongoId' refers to (MongoDB instance identifier) or what the 'applicationStatus' enum values mean in context. The description doesn't add meaningful semantics beyond what's already visible in the schema structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('mongo.changeStatus') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being modified (a MongoDB instance/container) or what 'changing status' means in practical terms. This is essentially a tautology of the name rather than a clear purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. The sibling tools list includes other MongoDB-related tools (dokploy_mongo_start, dokploy_mongo_stop, dokploy_mongo_update, etc.), but the description doesn't explain how this tool differs from those or when it's appropriate to use. There's no mention of prerequisites, constraints, or typical use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mongo_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal context by specifying 'GET', which aligns with read-only behavior. However, it doesn't disclose additional traits like rate limits, authentication needs, or what 'mongo.one' refers to (e.g., a MongoDB instance). With annotations doing heavy lifting, the description adds some value but lacks rich behavioral details.

  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 brief with two lines, but it's not front-loaded with key information. The first line '[mongo] mongo.one (GET)' is cryptic, and the parameter listing is basic. While concise, it lacks clarity and structure that would help an agent quickly understand the tool's function.

  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 1 parameter with 0% schema coverage, no output schema, and annotations covering safety, the description is incomplete. It doesn't explain the tool's purpose, parameter semantics, or expected output, leaving significant gaps. For a tool with a single required parameter, more context is needed to guide effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'mongoId (string, required)' but doesn't explain what 'mongoId' represents (e.g., an identifier for a MongoDB resource), its format, or where to obtain it. This adds minimal meaning beyond the schema's type and requirement, failing to fully address the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[mongo] mongo.one (GET)' restates the tool name and adds HTTP method, but lacks a clear verb+resource statement. It doesn't specify what the tool actually does (e.g., retrieve a MongoDB instance by ID) or distinguish it from sibling tools like 'dokploy_mongo_get' (which doesn't exist in the list) or other 'one' tools. The purpose is vague beyond being a GET operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions, and with many sibling tools (e.g., 'dokploy_mongo_search', 'dokploy_mongo_getAll'), there's no indication of when this specific tool is appropriate. This leaves the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mongo_rebuildC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, implying a state-changing action, but doesn't elaborate on what 'rebuild' entails behaviorally—such as whether it restarts services, reinitializes data, or affects availability. It doesn't contradict annotations, but provides minimal additional context beyond them.

  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 brief but poorly structured—it mixes tool identification with parameter listing in a single line. While not verbose, it lacks front-loading of key information (e.g., purpose first). The formatting as a code-like snippet reduces readability, though it avoids unnecessary fluff.

  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 (a state-changing operation on a database), lack of output schema, and low schema coverage, the description is inadequate. It doesn't explain what 'rebuild' does, potential side effects, success indicators, or error conditions. With annotations providing some safety hints but no behavioral details, the description leaves critical gaps for an agent to use the tool effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'mongoId' as a required parameter without explaining its format (e.g., UUID, name) or where to obtain it. This adds little meaning beyond the schema's type and requirement, failing to clarify the parameter's purpose or constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('mongo.rebuild') and method ('POST'), which is tautological. It doesn't explain what 'rebuild' means for a MongoDB resource—whether it's rebuilding indexes, containers, or something else. While it mentions the resource ('mongo'), the verb 'rebuild' remains vague without context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the MongoDB instance must be deployed), exclusions (e.g., not for stopped instances), or sibling tools like 'dokploy_mariadb_rebuild' or 'dokploy_mysql_rebuild' for comparison. This leaves the agent guessing about appropriate contexts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mongo_reloadC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds minimal behavioral context by specifying it's a POST request, implying a state-changing action, but doesn't elaborate on what 'reload' does (e.g., restarts service, reloads config) or its effects (e.g., downtime, performance impact). It doesn't contradict annotations, but adds little beyond them.

  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 brief but under-specified rather than concise. It includes the tool signature and parameter names, which is structured, but lacks meaningful content. The two lines are front-loaded with basic info, but more substance is needed to be truly helpful.

  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 (state-changing operation with 2 parameters), lack of output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'reload' means, what the parameters do, or what to expect as a result. Annotations provide some safety hints, but the description fails to add necessary operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameters 'mongoId' and 'appName' but gives no semantic meaning (e.g., what mongoId refers to, what appName is used for). It doesn't compensate for the lack of schema descriptions, leaving parameters largely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[mongo] mongo.reload (POST)' restates the tool name with minimal context. It mentions 'mongo' and 'reload' but doesn't specify what resource is being reloaded (e.g., a MongoDB instance, service, or configuration) or what 'reload' entails. Compared to siblings like 'dokploy_mariadb_reload' and 'dokploy_postgres_reload', it doesn't differentiate its specific purpose for MongoDB.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, expected outcomes, or when not to use it. With many sibling tools for managing MongoDB (e.g., 'dokploy_mongo_start', 'dokploy_mongo_stop', 'dokploy_mongo_rebuild'), there's no indication of how 'reload' differs or when it's appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mongo_stopC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these annotations but adds minimal behavioral context beyond them. It mentions 'POST' method, implying a state-changing action, but doesn't describe effects like service downtime, reversibility, or required permissions. With annotations covering basic safety, the description adds some value but lacks operational details.

  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 brief but inefficiently structured. It includes redundant information like '[mongo]' and 'mongo.stop', and the parameter listing is minimal without adding context. While not verbose, it lacks front-loaded clarity and wastes space on obvious details rather than providing actionable information.

  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 (a state-changing operation with no output schema and low schema coverage), the description is inadequate. It doesn't explain the outcome of stopping, error conditions, or integration with sibling tools. Without annotations covering all behavioral aspects and no output schema, the description fails to provide sufficient context for safe and effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'mongoId' as a required string parameter but provides no semantic meaning—what this ID represents, where to find it, or format constraints. The description adds minimal value beyond the schema's structural definition, failing to clarify parameter purpose or usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('mongo.stop') without adding meaningful context about what 'stop' actually does. It doesn't specify whether this stops a MongoDB service, container, deployment, or process, nor does it explain what happens when stopped. The description is essentially a tautology of the tool name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 doesn't mention prerequisites (e.g., the MongoDB instance must be running), what happens after stopping, or when to use sibling tools like 'dokploy_mongo_start' or 'dokploy_mongo_changeStatus'. No usage 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_mounts_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description's burden is lower. The description adds minimal value by specifying 'GET' which aligns with readOnlyHint, but doesn't provide additional context about what 'mounts.one' returns, error conditions, or any system-specific behaviors. No contradiction with annotations exists, but the description adds little beyond what annotations already declare.

  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 extremely concise - just two lines showing the endpoint and parameter. While this avoids waste, it's arguably under-specified rather than appropriately concise. The structure is clear (endpoint then parameter list), but the content is so minimal that it fails to provide necessary context. It's front-loaded with the endpoint, but that endpoint name itself isn't self-explanatory.

  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 simplicity (1 parameter, no output schema) and rich annotations, the description is incomplete. It doesn't explain what the tool returns (mount details? status?), doesn't provide context about mounts in the Dokploy system, and doesn't differentiate this from other mount operations. While annotations cover safety aspects, the description fails to provide the operational context needed to use this tool effectively alongside its many siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'mountId (string, required)' which matches the schema, but provides no semantic context - what a mountId is, where to find it, format expectations, or examples. The description doesn't explain what the parameter represents or how it's used in the operation, leaving significant gaps despite the single parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[mounts] mounts.one (GET)' is tautological - it essentially repeats the tool name and adds the HTTP method. It doesn't specify what the tool actually does (e.g., retrieve details of a specific mount). While it mentions 'mounts' which hints at the resource, it lacks a clear verb-action combination that distinguishes it from sibling mount tools like dokploy_mounts_allNamedByApplicationId or dokploy_mounts_listByServiceId.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention what differentiates this 'one' operation from other mount-related tools in the sibling list, nor does it specify any prerequisites, context requirements, or typical use cases. The agent receives no usage direction beyond the minimal parameter information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mounts_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (accepts unknown parameters). The description adds no behavioral context beyond what annotations already declare. No information about permissions, side effects, error conditions, or response format is provided, but annotations cover the basic safety profile adequately.

  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 technically concise but structurally poor. It wastes space repeating 'mounts.update (POST)' which adds little value, then presents a parameter list without meaningful organization or explanation. While brief, it's not effectively structured to aid understanding.

  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?

  For a complex update tool with 15 parameters, 0% schema coverage, no output schema, and no annotations explaining domain-specific behavior, the description is severely inadequate. It doesn't explain what a mount is, what fields can be updated, how updates affect running services, or what the response contains. The annotations provide basic safety hints but don't compensate for the missing domain context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 15 parameters (only 1 required), the description merely lists parameter names and basic types without explaining their meaning, relationships, or constraints. It doesn't clarify how parameters interact (e.g., that 'type' determines which of hostPath/volumeName/filePath/content is relevant) or what 'mountId' refers to. The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name 'mounts.update' with minimal context. It doesn't explain what a 'mount' is in this system or what specific aspects are being updated. While it mentions 'POST' indicating an HTTP method, this adds little semantic value beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. Given the sibling tools list includes dokploy_mounts_create, dokploy_mounts_one, dokploy_mounts_remove, and dokploy_mounts_listByServiceId, there's no indication of when update is appropriate versus create, delete, or read operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mysql_changeStatusC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false (mutation), destructiveHint=false (safe), idempotentHint=false (non-idempotent), and openWorldHint=true (flexible inputs). The description doesn't contradict these but adds no behavioral context beyond the POST method hint. It lacks details on permissions, side effects (e.g., if status changes affect database availability), rate limits, or response format. With annotations covering basic safety, the description adds minimal value.

  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 brief but poorly structured: it includes redundant info (POST method, parameter list) that's already in the schema, and the front-loaded content is just the tool name. It wastes space on formatting (brackets, parentheses) without adding value. However, it's not overly verbose, so it avoids a lower score for bloat.

  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 a mutation tool with no output schema, 0% schema coverage, and annotations that only hint at behavior, the description is incomplete. It doesn't explain what the tool does operationally, when to use it, parameter meanings, or expected outcomes. For a tool that changes application status—a potentially critical operation—this leaves significant gaps for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters but only repeats schema info (names and enum values) without explaining semantics: e.g., what mysqlId refers to (MySQL instance ID?), what each applicationStatus value means (e.g., 'running' vs 'idle'), or format constraints. It fails to compensate for the coverage gap, adding little meaning beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the name/title with minimal elaboration ('[mysql] mysql.changeStatus (POST)'), which is tautological. It doesn't specify what 'changeStatus' actually does (e.g., update MySQL application state), nor does it differentiate from sibling tools like dokploy_mysql_start or dokploy_mysql_stop, which likely manage similar states. The purpose is vague beyond the literal name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. Sibling tools include dokploy_mysql_start, dokploy_mysql_stop, dokploy_mysql_update, and other status-related tools (e.g., dokploy_mariadb_changeStatus), but the description provides no context on distinctions, prerequisites, or exclusions. Usage is entirely implied, leaving the agent to guess.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mysql_deployC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, but the description adds minimal context by specifying it's a POST request, implying a state-changing action. However, it doesn't elaborate on what 'deploy' entails (e.g., provisioning, configuration, starting), potential side effects, or error conditions, leaving behavioral gaps despite annotations.

  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 brief but inefficiently structured; it includes redundant information like '(POST)' which is implied by annotations, and the parameter list is minimal but not front-loaded with critical usage details. It avoids verbosity but lacks effective organization.

  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 a deployment tool with no output schema and 0% schema description coverage, the description is inadequate. It doesn't explain what 'deploy' does, expected outcomes, or error handling, making it incomplete for effective agent use despite annotations providing some safety context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'mysqlId' as a required parameter without explaining its meaning (e.g., an identifier for an existing MySQL configuration). This adds little value beyond the schema, failing to compensate for the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[mysql] mysql.deploy (POST)' which partially indicates the resource (MySQL) and action (deploy), but lacks specificity about what 'deploy' means in this context. It doesn't distinguish from sibling tools like dokploy_mysql_create, dokploy_mysql_start, or dokploy_mysql_rebuild, leaving the exact purpose ambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether a MySQL instance must exist first), nor does it reference sibling tools like dokploy_mysql_create or dokploy_mysql_start for comparison, leaving usage unclear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mysql_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), which already tell the agent this is a safe, non-destructive, repeatable operation. The description adds minimal value beyond the annotations - it only confirms the HTTP method is GET. It doesn't provide any additional behavioral context like rate limits, authentication requirements, or what specific MySQL resource is being retrieved.

  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 extremely concise - arguably too concise. While it's structured with clear labeling of parameters, the content is insufficient. The two-line format is efficient but under-specified. Every sentence should earn its place, and here the minimal content doesn't provide enough value to justify even this brevity.

  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 database operations and the complete lack of output schema, the description is inadequate. While annotations provide good safety information, the description doesn't explain what MySQL resource is being retrieved, what information is returned, or how this tool fits into the broader MySQL management context. For a tool that presumably retrieves critical infrastructure information, this level of documentation is insufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and only one parameter (mysqlId), the description provides no semantic information about what mysqlId represents. The schema only indicates it's a required string with minimum length 1, but the description doesn't explain what this identifier refers to, how to obtain valid values, or what format it should have. The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[mysql] mysql.one (GET)' is essentially a tautology that restates the tool name and adds the HTTP method. It doesn't specify what the tool actually does - whether it retrieves a MySQL database instance, configuration, status, or something else. While 'GET' implies retrieval, the purpose remains vague and doesn't distinguish this tool from other MySQL-related tools in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance about when to use this tool versus alternatives. There are multiple MySQL-related tools in the sibling list (dokploy_mysql_changeStatus, dokploy_mysql_create, dokploy_mysql_deploy, etc.), but the description offers no context about when this specific 'one' tool is appropriate versus those other MySQL operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mysql_removeC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide critical behavioral hints: destructiveHint=true indicates irreversible data loss, readOnlyHint=false confirms it's a mutation, idempotentHint=false suggests repeated calls may have side effects, and openWorldHint=true implies the mysqlId may not be pre-known. The description adds no context beyond these annotations, such as what exactly gets destroyed (e.g., database, volumes, backups), authentication requirements, or rate limits. However, it doesn't contradict the annotations, so it meets the lower bar set by their presence.

  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 concise with only two lines, but it's poorly structured and under-specified. The first line '[mysql] mysql.remove (POST)' is redundant with the tool name, and the parameters section merely repeats the schema without adding value. While brief, it wastes space on unhelpful information rather than being efficiently informative.

  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?

  For a destructive tool with one parameter and no output schema, the description is incomplete. It lacks essential context: what the tool removes (e.g., a MySQL instance, associated data), the consequences of removal, any confirmation steps, or error handling. Annotations cover safety aspects, but the description doesn't add necessary operational details, making it inadequate for safe and correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'mysqlId' as a required parameter but provides no semantic meaning beyond what the schema already states (a string with minLength 1). With 0% schema description coverage, the description fails to compensate by explaining what mysqlId represents (e.g., a database identifier, container name, or UUID), its format, or where to find it. This leaves the parameter's purpose ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'mysql.remove (POST)' is essentially a tautology that restates the tool name and HTTP method without explaining what the tool actually does. It doesn't specify what resource is being removed (a MySQL database instance, container, or configuration) or what the removal entails. While it mentions 'mysql' as a resource type, this is already evident from the tool name, making it minimally informative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools list includes other MySQL-related tools like 'dokploy_mysql_create', 'dokploy_mysql_update', and 'dokploy_mysql_deploy', there is no indication of prerequisites, dependencies, or scenarios where removal is appropriate versus other operations. This leaves the agent without context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mysql_saveEnvironmentC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, implying it's a write operation, which aligns with readOnlyHint=false. However, it doesn't provide any additional behavioral context about what 'saving environment' entails - whether it overwrites, merges, validates, or has side effects. With annotations covering basic safety, the description adds minimal value.

  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 technically concise but under-specified. It wastes space on obvious formatting ('[mysql] mysql.saveEnvironment (POST)') and provides a parameter list that adds little value beyond what's in the schema. While not verbose, it fails to use its limited space effectively to convey meaningful information about the tool's purpose or usage.

  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?

  For a write operation (POST) with 2 parameters and 0% schema coverage, the description is inadequate. It doesn't explain what 'saving environment' means operationally, what format 'env' should take, what happens to existing environment settings, or what the tool returns. With no output schema and minimal annotations, the description should provide much more context about this mutation's behavior and outcomes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It only lists parameter names and types ('mysqlId (string, required)' and 'env (any, required)') without explaining what these mean. 'env' being type 'any' with no explanation is particularly problematic - is this JSON, key-value pairs, a string? The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('mysql.saveEnvironment') and lists parameters without explaining what the tool actually does. It doesn't specify what 'saveEnvironment' means - whether it creates, updates, or configures environment variables for a MySQL instance. This is a tautology that provides no meaningful purpose clarification beyond what's already in 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling tools with 'saveEnvironment' in their names (for mariadb, mongo, postgres, redis, and application contexts), but the description doesn't differentiate this MySQL-specific version or explain when environment saving is appropriate versus other MySQL operations like create, update, or deploy.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_allC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which fully cover safety and idempotency. The description adds no behavioral context beyond what annotations declare—it doesn't mention response format, pagination, rate limits, or authentication requirements. However, it doesn't contradict annotations, so it meets the lower bar with annotations present but adds minimal value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While the description is brief, it's under-specified rather than concise. The single bracketed phrase '[notification] notification.all (GET)' fails to convey useful information and wastes space on redundant details. It lacks a clear, front-loaded purpose statement, making it inefficient despite its short length.

  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 zero parameters and rich annotations, the description is incomplete. It doesn't explain what the tool returns (no output schema exists), its scope (e.g., all notifications across the system or per user), or any side effects. For a read operation in a complex notification subsystem, the description should clarify the resource being accessed and the nature of the returned data, which it fails to do.

  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 schema description coverage is 100% (empty schema). With no parameters to document, the description isn't expected to add parameter semantics. The baseline for zero parameters is 4, as there's nothing to compensate for, and the schema adequately indicates no inputs are required.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose1/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[notification] notification.all (GET)' is a tautology that merely restates the tool name and adds the HTTP method. It fails to specify what the tool actually does (e.g., list notifications, retrieve notification settings, fetch all notification channels). The description provides no meaningful verb-resource combination, making it impossible to distinguish from sibling notification tools like 'dokploy_notification_one' or 'dokploy_notification_createDiscord'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions. With many sibling notification tools available (create, update, remove, test connections), the agent receives zero direction on whether this tool is for listing, fetching, or managing notifications, or how it differs from other notification-related operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_createCustomC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. The description adds minimal behavioral context by specifying it's a POST request, implying creation, but doesn't elaborate on effects like what gets created, permissions needed, or response format. With annotations covering basic traits, the description adds some value 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 concise but poorly structured. It front-loads minimal information and then lists parameters without integration into the purpose. While not verbose, the structure doesn't effectively communicate the tool's function, making it less helpful despite brevity.

  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 has 10 parameters, no output schema, and annotations that don't fully explain behavior, the description is incomplete. It lacks details on what the tool creates, how it interacts with the system, expected outcomes, and differentiation from siblings. For a creation tool in a complex notification system, this leaves the agent under-informed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameters with types and optionality, adding basic semantics beyond the schema. However, it doesn't explain what each parameter means (e.g., what 'appBuildError' triggers, what 'endpoint' is for), leaving significant gaps in understanding for a tool with 10 parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description only restates the tool name with minimal context ('[notification] notification.createCustom (POST)'), which is essentially tautological. It doesn't clearly state what the tool does beyond implying it creates something related to notifications. While it lists parameters, it doesn't articulate the core function or resource being created.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. Given the sibling tools include many other notification creation tools (e.g., dokploy_notification_createDiscord, dokploy_notification_createEmail), the description fails to differentiate this custom notification tool from those, leaving the agent without context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_createLarkC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these annotations, but also adds minimal behavioral context. The POST method hint suggests creation, but there's no information about what gets created, whether it's idempotent (contradicted by annotations saying it's not), what permissions are required, or what happens on success/failure. With annotations covering basic safety profile, the description adds little additional behavioral insight.

  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 concise but under-specified rather than efficiently informative. The first line is redundant with the tool name, and the parameter list is essentially a reformatted version of the schema without added value. While it's not verbose, it fails to use its limited space effectively to convey meaningful information beyond what's already apparent from structured fields.

  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?

  For a tool with 9 required parameters, 0% schema description coverage, no output schema, and annotations that only cover basic safety hints, the description is severely incomplete. It doesn't explain what the tool creates, what the parameters mean, what the expected response looks like, or how this fits into the broader notification system. Given the complexity and lack of structured documentation, the description should provide much more context than it does.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage for 9 required parameters, the description carries the full burden of explaining parameter meanings. While it lists parameter names and types, it provides no semantic explanation of what each boolean flag controls (e.g., what 'appBuildError' actually means in context) or what the 'name' and 'webhookUrl' parameters represent. The parameter list adds minimal value beyond what's already visible in the schema structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[notification] notification.createLark (POST)' which is essentially a tautology of the tool name and HTTP method. It doesn't explain what the tool actually does - whether it creates a Lark notification configuration, sends a notification to Lark, or something else. While it lists parameters, it doesn't articulate the core purpose beyond restating 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include dokploy_notification_createDiscord, dokploy_notification_createSlack, dokploy_notification_createTeams, etc., there's no indication of when to choose Lark over other notification platforms or what distinguishes this tool from other notification creation tools in the system.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_createNtfyC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these annotations but adds minimal behavioral context beyond the parameter list. It doesn't explain what happens when the notification is created, whether it's immediately active, or any side effects.

  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 technically concise but poorly structured. It front-loads redundant information (name + HTTP method) then dumps a parameter list. While brief, it fails to communicate essential information efficiently - every sentence should earn its place, and the parameter listing without explanation doesn't add sufficient value.

  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?

  For a creation tool with 11 required parameters, 0% schema coverage, no output schema, and no annotations explaining behavior, the description is severely incomplete. It doesn't explain what gets created, how to use it, what the parameters mean, or what the expected outcome is. The agent would struggle to use this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 11 required parameters, the description merely lists parameter names and types without explaining their meaning. It doesn't clarify what 'appBuildError', 'databaseBackup', etc. represent (notification triggers?), what 'priority' values mean, or how 'serverUrl' and 'topic' relate to Ntfy configuration.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and HTTP method without explaining what the tool actually does. It lists parameters but doesn't state the purpose - creating an Ntfy notification configuration in Dokploy. This is essentially a tautology of the name/title with added parameter listing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 versus the many other notification creation tools (createCustom, createDiscord, createEmail, etc.). The description provides no context about when Ntfy notifications are appropriate or what distinguishes this from sibling notification tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_createTeamsC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these annotations, but adds minimal behavioral context. The POST method hint suggests creation, but there's no information about what gets created (notification configuration?), whether this requires specific permissions, rate limits, or what happens on success/failure. With annotations covering basic safety, the description adds little additional behavioral insight.

  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 technically concise (just parameter listing), but this conciseness comes at the cost of usefulness. The structure is poor - it starts with a redundant name restatement, then dumps a parameter list without context. While not verbose, it's under-specified rather than efficiently informative.

  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?

  For a 9-parameter creation tool with no output schema and 0% schema description coverage, this description is severely incomplete. It doesn't explain the tool's purpose, when to use it, what the parameters mean, what gets created, or what the response contains. The annotations provide basic safety information, but the description fails to address the complexity of configuring a multi-parameter notification channel.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 9 parameters have descriptions in the schema. The description merely lists parameter names and types without explaining what they mean. For example, what does 'appBuildError' control? When should 'serverThreshold' be true? What format should 'webhookUrl' follow? The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('notification.createTeams') and lists parameters without explaining what the tool actually does. It doesn't specify what kind of notification is being created, for what purpose, or what 'Teams' refers to (Microsoft Teams integration? Team notifications?). This is essentially a tautology that adds little 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is absolutely no guidance about when to use this tool versus alternatives. The sibling tools list includes many other notification creation tools (createDiscord, createEmail, createSlack, etc.), but the description provides no context about when Teams notifications are appropriate or how this differs from other notification channels.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_receiveNotificationC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint=true. The description doesn't contradict these annotations, but adds minimal behavioral context - only that it's a POST endpoint. It doesn't explain what 'receiveNotification' actually does behaviorally: does it trigger alerts, store data, forward to other systems? For a tool with 7 parameters, more behavioral explanation would be helpful.

  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 technically concise but poorly structured. It front-loads with '[notification] notification.receiveNotification (POST)' which doesn't communicate purpose. The parameter listing is organized but lacks explanatory context. While not verbose, the description fails to use its limited space effectively to convey meaningful information beyond what's already in the schema.

  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 with 0% schema description coverage, no output schema, and annotations that only cover basic hints, the description is severely incomplete. It doesn't explain what the tool does, when to use it, what the parameters mean, what happens when called, or what to expect in response. For a notification-related POST operation in a complex system with many sibling tools, this leaves critical gaps for agent understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. While it lists all 7 parameters with types and requirements, it provides zero semantic meaning. What does 'ServerType' represent? What units for 'Value' and 'Threshold'? What format for 'Timestamp'? What is the 'Token' used for? The parameter list is essentially a restatement of the schema without added value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name 'notification.receiveNotification' without explaining what it does. It lists parameters but doesn't state the purpose - whether this sends a notification, processes incoming notifications, or logs them. Compared to sibling tools like 'dokploy_notification_createDiscord' or 'dokploy_notification_testEmailConnection', this tool's function is unclear from the description alone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. With many sibling notification tools (createCustom, createDiscord, createEmail, etc.), there's no indication whether this is for receiving system alerts, processing webhook payloads, or another purpose. No prerequisites, context, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_testEmailConnectionC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. However, it adds no behavioral context beyond this—no mention of what 'testing' entails (e.g., sends a test email, returns success/failure), potential side effects (e.g., email sent to recipients), or error handling. With annotations covering basic traits, the description adds minimal value, scoring baseline for partial disclosure.

  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 brief but inefficiently structured—it front-loads redundant name/HTTP method info and lists parameters without explanation, wasting space. While not verbose, it lacks meaningful content, making it under-specified rather than concise. Every sentence (or line) doesn't earn its place with useful information.

  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 (6 required parameters, no output schema, annotations with mixed hints), the description is incomplete. It doesn't explain the testing behavior, expected outcomes, or error scenarios. Without output schema or rich parameter details, the agent lacks sufficient context to use the tool effectively, especially for a non-idempotent operation involving sensitive data like passwords.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameter names and types but adds no semantic meaning—it doesn't explain what 'smtpServer' should contain (e.g., hostname), 'toAddresses' format, or purpose of each field. This fails to compensate for the schema gap, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name with minimal context ('[notification] notification.testEmailConnection (POST)'), which is essentially a tautology. It doesn't specify what 'testEmailConnection' actually does—whether it sends a test email, validates SMTP settings, or performs another action. While it hints at notification/email testing, the purpose remains vague and lacks a clear verb+resource statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The sibling tools include other notification testing tools (e.g., testDiscordConnection, testSlackConnection), but the description doesn't differentiate this email-specific test from those or explain prerequisites like needing SMTP credentials. Usage context is entirely missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_testLarkConnectionC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide basic hints (non-read-only, non-destructive, non-idempotent, open-world), but the description adds minimal behavioral context by specifying it's a POST request, implying it may send data or trigger an action. However, it doesn't disclose what the tool actually does (e.g., sends a test ping, validates connectivity, returns a status), rate limits, authentication needs, or expected outcomes. With annotations present, the bar is lower, but the description adds only limited value beyond them.

  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 brief and front-loaded with the tool name and method, but it includes redundant information (the tool name in brackets) and lacks structure. It's concise but under-specified, with the parameter list adding little value. Every sentence doesn't fully earn its place due to the lack of substantive content.

  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 has one parameter with 0% schema coverage, no output schema, and annotations that don't fully explain behavior, the description is incomplete. It doesn't clarify the tool's purpose, usage, or what happens when invoked. For a notification testing tool, this leaves critical gaps in understanding how to use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists the parameter 'webhookUrl' as a required string but provides no semantics—what the URL is for, format expectations, or example values. The description repeats what the schema already defines (parameter name and type) without adding meaning, failing to address the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('notification.testLarkConnection') and adds the HTTP method (POST), which is tautological. It mentions 'notification' but doesn't specify what the tool actually does—whether it sends a test notification, validates a webhook URL, or performs another action. The purpose is vague and lacks a clear verb+resource combination.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 any context, prerequisites, or exclusions. Given the sibling tools include other notification test tools (e.g., testDiscordConnection, testSlackConnection), the lack of differentiation is a significant gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_testSlackConnectionC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description doesn't add meaningful behavioral context beyond what annotations provide. Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint=true. The description doesn't explain what 'testSlackConnection' actually does behaviorally - whether it sends a test notification, validates webhook functionality, returns connection status, or has side effects. However, it doesn't contradict the annotations either.

  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 concise but poorly structured. It wastes space on redundant information (repeating the tool name and HTTP method) while lacking meaningful content. The parameter listing is presented but without useful context. While brief, it's not effectively front-loaded with the most important information about what the tool does.

  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?

  For a tool with 2 parameters, 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is insufficient. It doesn't explain what the tool returns, what constitutes a successful test, error conditions, or how this differs from other Slack-related notification tools. The description leaves critical gaps for understanding and using this tool effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description carries full burden for parameter documentation. It lists parameter names (webhookUrl, channel) but provides no semantic explanation of what these parameters represent, their expected formats, or how they're used in the connection test. The description doesn't compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('notification.testSlackConnection') and HTTP method ('POST') without explaining what the tool actually does. It doesn't specify what 'testSlackConnection' means - whether it sends a test message, validates credentials, or performs some other verification. This is a tautology that provides minimal additional value beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. With multiple notification-related tools in the sibling list (including dokploy_notification_createSlack, dokploy_notification_updateSlack, and other testConnection tools for different platforms), there's no indication of when this specific Slack connection test should be used versus creating or updating Slack notifications.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_updateResendC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (safe), idempotentHint=true (repeatable), and openWorldHint=true (flexible). The description adds no behavioral context beyond what annotations already declare. It doesn't explain what 'updateResend' actually does behaviorally, what gets updated, what 'resend' means, or any side effects. However, it doesn't contradict the annotations either.

  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 technically concise (just the tool signature and parameter list), but it's under-specified rather than efficiently informative. The parameter list formatting is structured but adds no value beyond what's already in the schema. It wastes space repeating schema information without adding explanation.

  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?

  For a mutation tool with 14 parameters (2 required), 0% schema description coverage, no output schema, and complex sibling context (many notification_* tools), this description is severely incomplete. It doesn't explain what the tool does, when to use it, what the parameters mean, or what to expect as output. The annotations help with safety profile, but the functional understanding is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides only type information without descriptions. The description lists parameter names but adds zero semantic meaning - it doesn't explain what 'appBuildError', 'databaseBackup', 'notificationId', 'resendId', or any other parameters actually represent or how they affect the operation. For 14 parameters with no schema descriptions, this is inadequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name with minimal context. It mentions 'notification.updateResend (POST)' which repeats the name and adds the HTTP method, but doesn't explain what the tool actually does - what 'updateResend' means in practical terms, what notifications are being updated/resent, or what outcome to expect.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is absolutely no guidance about when to use this tool versus alternatives. The description doesn't mention any prerequisites, appropriate contexts, or sibling tools that might be relevant (like other notification_* tools). It provides zero decision-making help for an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_updateSlackC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (accepts unknown parameters). The description doesn't contradict these annotations, but adds minimal behavioral context beyond what's already in annotations. The '(POST)' notation implies an HTTP POST method, which aligns with the mutation annotation, but no additional behavioral details (like what happens when parameters are omitted, how the update affects existing settings, or response format) are provided.

  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 structured as a parameter list, which is somewhat organized but not front-loaded with purpose. It wastes space by repeating '[notification] notification.updateSlack (POST)' which adds little value. The parameter listing is comprehensive but could be more concise if integrated with meaningful context. While not verbose, it lacks efficiency in conveying essential information.

  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 (13 parameters, 0% schema coverage, no output schema) and annotations that cover basic behavioral traits, the description is insufficient. It doesn't explain what a 'Slack notification' is in this context, what gets updated, how the parameters interact, or what the expected outcome is. For a mutation tool with many undocumented parameters, more context is needed to guide proper usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 13 parameters have descriptions in the schema. The description lists all parameters with their types and required status, but provides no semantic meaning beyond what's already evident from the parameter names. For example, it doesn't explain what 'appBuildError' controls, what 'serverThreshold' means, or how 'webhookUrl' relates to Slack notifications. With 0% schema coverage and 13 parameters, the description fails to compensate adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name with minimal context. It states '[notification] notification.updateSlack (POST)' which repeats the name and adds the HTTP method, but doesn't explain what 'updateSlack' actually does. The description lacks a clear verb+resource statement that distinguishes this from sibling notification tools like 'dokploy_notification_createSlack' or 'dokploy_notification_testSlackConnection'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling notification tools (createSlack, updateSlack, testSlackConnection, plus other notification types), but the description offers no context about when this update operation is appropriate versus creating a new notification or testing an existing one. No prerequisites, conditions, or alternatives are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_updateTelegramC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (safe), idempotentHint=true (repeatable), and openWorldHint=true (flexible). The description doesn't contradict these annotations, but adds minimal behavioral context beyond what's already in structured data. It mentions 'POST' which aligns with mutation, but doesn't explain what 'update' entails, whether it merges or replaces settings, or what happens to unspecified parameters. With annotations covering the core behavioral traits, the description adds limited additional value.

  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 technically concise - just a header and parameter list - but this conciseness comes at the cost of being under-specified. While it doesn't waste words, it also doesn't provide the essential explanatory content needed for a tool with 14 parameters. The structure (header then parameter list) is logical but incomplete, as it lacks any explanatory prose about the tool's purpose or usage.

  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?

  For a mutation tool with 14 parameters, 0% schema description coverage, no output schema, and complex sibling relationships (multiple notification update tools), the description is severely incomplete. It doesn't explain what constitutes a successful update, what the response might contain, how this tool relates to other notification tools, or the semantics of the numerous boolean parameters. The annotations help somewhat, but the description fails to provide the contextual completeness needed for effective tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 14 parameters (12 optional, 2 required), the description merely lists parameter names and types without explaining their meaning or relationships. The boolean parameters (appBuildError, databaseBackup, etc.) aren't explained as event triggers or notification settings. Required parameters notificationId and telegramId lack context about what they reference. The description fails to compensate for the complete lack of schema descriptions, leaving most parameters semantically unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology - it restates the tool name 'notification.updateTelegram' with minimal additional context. While it mentions 'POST' and lists parameters, it doesn't clearly articulate what the tool actually does (e.g., 'update Telegram notification settings for specific event types in Dokploy'). The description fails to provide a specific verb+resource combination that distinguishes this tool from its siblings like dokploy_notification_updateDiscord or dokploy_notification_updateEmail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool should be selected over other notification update tools, or what context would trigger its use. The agent receives no usage context beyond the parameter list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_setDefaultC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is mutable (readOnlyHint=false), non-destructive (destructiveHint=false), idempotent (idempotentHint=true), and open-world (openWorldHint=true). The description adds minimal context by specifying the HTTP method (POST), implying a write operation, but does not elaborate on behavioral traits like permissions needed, side effects, or rate limits. With annotations covering safety and idempotency, the description adds some value but is sparse on details.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) and a parameter list that adds little value. While not verbose, it lacks efficient structuring—the parameter listing is unnecessary without explanation, and the overall text could be more streamlined to convey purpose clearly.

  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 (a mutation with one parameter) and lack of output schema, the description is incomplete. It does not explain what 'setDefault' does, the outcome, or error conditions. Annotations provide some behavioral hints, but the description fails to add necessary context for effective use, especially with 0% schema description coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only defines 'organizationId' as a required string. The description lists the parameter but provides no semantic meaning (e.g., what an organization ID is, where to find it, format examples). It fails to compensate for the lack of schema descriptions, leaving the parameter's purpose unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title without explaining what 'setDefault' means for an organization. It mentions the HTTP method (POST) and lists the parameter, but fails to specify the action's effect (e.g., setting an organization as default for the user, system, or context). This is a tautology that adds little beyond the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., user must have permissions), or sibling tools like 'dokploy_organization_active' or 'dokploy_organization_all' that might be related. The description lacks any usage instructions or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_cleanPatchReposC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true (implying data deletion or irreversible changes) and readOnlyHint=false (non-read operation), which the description doesn't contradict. However, it adds minimal context beyond annotations—mentioning it's a POST request hints at mutation but lacks details on what gets destroyed (e.g., old patch files, temporary repos) or any prerequisites. With annotations covering safety, this earns a baseline score for slight added value.

  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 brief but not front-loaded with essential information; it starts with redundant details like '[patch]' and HTTP method. While concise, it under-specifies the tool's purpose and parameters, making it inefficient in conveying necessary context. Every sentence doesn't fully earn its place due to lack of clarity.

  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 (destructive operation with one parameter), lack of output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'clean' does, the impact of serverId, or expected outcomes, leaving significant gaps for an agent to understand and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'serverId (string, optional)' but provides no semantic meaning—what a serverId is, how to obtain it, or what happens if omitted (e.g., cleans all servers' patch repos). This adds little beyond the schema's type information, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('patch.cleanPatchRepos') and HTTP method ('POST') without explaining what 'cleanPatchRepos' means. It doesn't specify what resource is being cleaned (patch repositories) or what 'clean' entails (e.g., delete, archive, remove unused). This is a tautology that adds little beyond the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., dokploy_patch_delete, dokploy_patch_update, dokploy_settings_cleanAll), the description fails to differentiate this tool's specific use case, such as cleaning patch repositories versus deleting patches or general cleanup operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide good coverage: readOnlyHint=false (write operation), destructiveHint=false (non-destructive), idempotentHint=false (not idempotent), openWorldHint=true (can create new resources). The description adds no behavioral context beyond what annotations already declare - no information about what gets created, authentication requirements, rate limits, or side effects. However, there's no contradiction with annotations, and annotations cover the essential safety profile, so a baseline 3 is appropriate.

  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 technically concise (just parameter listing), but it's poorly structured and front-loaded with irrelevant formatting ('[patch] patch.create (POST)'). The parameter list is presented but without meaningful organization or prioritization. While brief, it wastes space on redundant information (tool name) rather than providing value.

  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 6 parameters with 0% schema coverage, no output schema, and annotations that only cover basic safety hints, the description is severely incomplete. It doesn't explain what a patch is, what the tool returns, how parameters interact, or what the expected outcomes are. For a write operation (readOnlyHint=false) with multiple parameters, this level of documentation is inadequate for effective tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The description merely lists parameter names and basic types without explaining what they mean (e.g., what 'filePath' represents, what 'content' contains, what 'type' enum values actually do, what 'applicationId' and 'composeId' refer to). This minimal parameter listing doesn't compensate for the complete lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology - it restates the tool name 'patch.create' without explaining what a 'patch' is in this context or what resource it operates on. While it mentions 'POST' and lists parameters, it doesn't state what the tool actually does (e.g., creates a patch file, applies a patch to a system, etc.). The sibling tools include other patch-related tools like 'dokploy_patch_delete' and 'dokploy_patch_update', but this description doesn't differentiate from them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is absolutely no guidance on when to use this tool versus alternatives. The description provides no context about appropriate use cases, prerequisites, or relationships to sibling tools like 'dokploy_patch_update' or 'dokploy_patch_delete'. An agent would have no idea when this tool is the correct choice.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_ensureRepoC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide basic hints (not read-only, not destructive, not idempotent, open world), but the description adds minimal context by specifying it's a POST operation. However, it doesn't explain what 'ensure' means operationally - whether it creates if missing, validates existence, or performs some configuration. For a non-idempotent, non-read-only tool, more behavioral detail would be helpful.

  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 technically concise but under-specified. It wastes space on obvious formatting ('[patch]', HTTP method) while lacking substantive content. The structure with a parameter list is organized, but the content is insufficient. It's not verbose, but it's not helpful either.

  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 2 parameters with 0% schema coverage, no output schema, and annotations that only provide basic hints, the description is inadequate. It doesn't explain what the tool returns, what 'ensuring a repo' entails operationally, or how it relates to other patch tools. For a POST operation with openWorldHint=true, more context about side effects and outcomes is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It merely lists parameter names and types without explaining what 'id' represents (repository ID? patch ID? entity ID?) or what the 'type' enum values ('application', 'compose') mean in this context. The description fails to compensate for the schema's lack of descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('patch.ensureRepo') and HTTP method ('POST') without explaining what the tool actually does. It provides a list of parameters but no functional explanation of what 'ensureRepo' means - whether it creates, verifies, or configures a repository. This is tautological rather than clarifying.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools related to patches (dokploy_patch_byEntityId, dokploy_patch_create, dokploy_patch_delete, etc.), there's no indication of how this tool differs or when it should be selected. No context, prerequisites, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_markFileForDeletionC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is not read-only, not destructive, not idempotent, and operates in an open world. The description adds no behavioral details beyond this—it does not explain what 'marking for deletion' entails (e.g., if it's reversible, requires permissions, or affects system state). However, it does not contradict the annotations, so it meets the lower bar with annotations present but adds minimal context.

  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 brief and front-loaded with the tool name and HTTP method, but it wastes space by repeating the name and listing parameters without explanation. It could be more structured by separating purpose from parameters, but it avoids unnecessary verbosity.

  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 (a mutation tool with 3 parameters, 0% schema coverage, no output schema), the description is inadequate. It lacks details on what the tool does, when to use it, parameter meanings, and expected outcomes. Annotations provide some safety hints, but the description fails to compensate for the missing context, especially for a tool that likely modifies system state.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameters (id, type, filePath) but does not explain their meanings—what 'id' refers to, what 'application' vs 'compose' types indicate, or what 'filePath' represents. This adds minimal value beyond the schema's structure, insufficient for the low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('patch.markFileForDeletion') and HTTP method ('POST'), which is tautological. It does not explain what 'markFileForDeletion' means—whether it schedules deletion, flags a file, or performs another action. The purpose is vague, as it lacks a clear verb and resource context 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 Guidelines1/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 prerequisites, context (e.g., after a patch operation), or related tools like 'dokploy_patch_delete' or 'dokploy_patch_cleanPatchRepos'. This leaves the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), which already tell the agent this is a safe, non-destructive, repeatable read operation. The description adds minimal value by specifying it's a GET operation, but doesn't provide any additional behavioral context beyond what annotations already cover. No contradiction with annotations exists.

  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 extremely concise - just two lines. However, this brevity comes at the cost of being under-specified rather than efficiently informative. The structure with 'Parameters:' heading is clear, but the content lacks substance. It's not verbose, but it's also not sufficiently informative.

  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 the Dokploy system with many sibling tools, no output schema, and 0% schema description coverage, this description is inadequate. It doesn't explain what a 'patch' is in this context, what data is returned, or how this tool fits into the broader patch management workflow. The annotations help, but the description itself leaves too many contextual gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'patchId (string, required)' but provides no semantic context about what a patchId is, what format it should have, or where to obtain it. With 0% schema description coverage and only one parameter, the description should compensate by explaining the parameter's meaning and purpose, but it merely repeats the parameter name without adding meaningful semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[patch] patch.one (GET)' which is tautological - it essentially repeats the tool name with a method. It doesn't explain what 'patch.one' refers to or what this GET operation actually retrieves. While it mentions 'GET', it doesn't specify what resource is being accessed or what the tool accomplishes 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools with 'patch' in their names (dokploy_patch_byEntityId, dokploy_patch_create, dokploy_patch_delete, etc.), but the description doesn't differentiate this tool from them or explain when this specific 'patch.one' operation is appropriate versus other patch-related operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_readRepoDirectoriesC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds no behavioral context beyond what annotations already declare, such as rate limits or authentication needs. No contradiction with annotations.

  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 brief but inefficiently structured. It front-loads redundant name/HTTP method info, then lists parameters without explanation. While concise, it wastes space on unhelpful repetition rather than adding value.

  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?

  For a tool with 3 parameters (0% schema coverage), no output schema, and no sibling differentiation, the description is inadequate. It lacks purpose, parameter semantics, and usage context, leaving the agent poorly informed despite good annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types but adds no semantic meaning (e.g., what 'id' refers to, what 'repoPath' expects). It fails to compensate for the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name with '[patch] patch.readRepoDirectories (GET)' and lists parameters, but doesn't explain what the tool actually does. It's a tautology that doesn't clarify the verb (read directories from a repository) or distinguish from siblings like 'dokploy_patch_readRepoFile'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 versus alternatives. The description doesn't mention context, prerequisites, or sibling tools like 'dokploy_patch_readRepoFile' for file reading versus directory listing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_toggleEnabledC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=false (non-idempotent), and openWorldHint=true (open-world). The description doesn't contradict these but adds minimal behavioral context beyond the parameter list. It doesn't explain what 'toggleEnabled' does to the patch state, whether it's reversible, or what the expected outcome is.

  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 brief but inefficiently structured. It repeats the tool name and HTTP method without adding value, then lists parameters without explanation. While concise, it wastes space on redundant information rather than providing useful content, making it under-specified rather than optimally concise.

  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?

  For a mutation tool with 0% schema description coverage and no output schema, the description is inadequate. It doesn't explain what a 'patch' is in this system, what toggling enabled does, what the expected response looks like, or any error conditions. Given the complexity implied by the sibling tools (e.g., patch management), more context is needed for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (patchId, enabled) but provides no semantic meaning: what a patchId is, what format it expects, or what 'enabled' toggles (e.g., activation status, visibility). This adds little beyond the schema's type constraints, leaving parameters largely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('patch.toggleEnabled') and HTTP method ('POST') without explaining what the tool actually does. It doesn't specify what resource 'patch' refers to or what 'toggleEnabled' means in context. While it lists parameters, this doesn't clarify the purpose beyond the tautological name restatement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or related tools among the many siblings (like dokploy_patch_create, dokploy_patch_update, dokploy_patch_delete). There's no indication of when this specific toggle operation is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_changeStatusC
  2.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, non-idempotent operation with open-world semantics. The description adds no behavioral context beyond what annotations provide - no information about what status changes mean, whether they're reversible, what permissions are required, or what side effects might occur. With annotations covering basic safety profile, the description adds minimal value.

  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 brief but inefficiently structured. It wastes space on the HTTP method (POST) which isn't helpful for an AI agent, and presents parameters in a bulleted format that duplicates schema information. While concise in word count, it doesn't front-load the most important information about what the tool actually does.

  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?

  For a status change operation with 2 parameters (0% schema coverage), no output schema, and annotations that only cover basic safety, the description is inadequate. It doesn't explain the purpose of status changes, what each status means, what happens when status is changed, or what the tool returns. The agent would struggle to use this tool correctly without additional context.

  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 0%, so the description must compensate. It lists both parameters (postgresId, applicationStatus) and the enum values for applicationStatus, which provides basic semantic meaning. However, it doesn't explain what postgresId refers to (instance ID? database name?) or what each status value means in practice (what does 'idle' vs 'running' vs 'done' indicate?). The description adds some value but leaves critical gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('postgres.changeStatus') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being changed (PostgreSQL instance? database? service?) or what 'changeStatus' means in practice. This is essentially a tautology of the name with parameter documentation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. Given the sibling tools include dokploy_postgres_start, dokploy_postgres_stop, and dokploy_postgres_update, there's clear overlap in functionality but no explanation of when this status change tool is appropriate versus those specific action tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_reloadC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint. The description doesn't contradict these annotations, but adds minimal behavioral context. It mentions it's a POST operation, implying a state change, but doesn't explain what 'reload' entails, potential side effects, or what happens during execution. Some value is added by specifying the HTTP method, but overall behavioral disclosure is limited.

  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 extremely concise (three lines) with no wasted words, but it's under-specified rather than appropriately concise. It uses a structured format with a header and bullet points, which is clear, but the content is insufficient. While front-loaded with the tool name, it doesn't effectively communicate purpose or usage.

  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 this is a state-changing operation (non-readOnly) with no output schema and 0% schema description coverage, the description is incomplete. It doesn't explain what the tool does, when to use it, what parameters mean, what happens during execution, or what to expect as a result. The annotations provide some safety profile, but the description adds minimal contextual value for a tool that presumably restarts or refreshes a PostgreSQL service.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It lists the two parameters (postgresId, appName) but provides no semantic meaning for either. It doesn't explain what these identifiers represent, where to find them, or how they relate to the reload operation. The description fails to compensate for the complete lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('postgres.reload') without explaining what 'reload' means in this context. It doesn't specify what resource is being reloaded (PostgreSQL service/configuration) or what the effect is. This is essentially a tautology that provides minimal additional information 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'dokploy_postgres_start', 'dokploy_postgres_stop', 'dokploy_postgres_rebuild', or 'dokploy_postgres_update', nor does it explain when a reload is appropriate versus other operations. No context or prerequisites are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_saveEnvironmentC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds minimal behavioral context beyond annotations—it specifies it's a POST request, implying a write operation, which aligns with readOnlyHint=false. However, it doesn't disclose critical details like what 'save' entails (overwrites, merges?), authentication needs, rate limits, or side effects. With annotations covering basic safety, the description adds some value 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 concise with two lines, but it's under-specified rather than efficiently informative. The first line repeats the tool name and method without adding value, and the parameter list lacks explanations. While it avoids verbosity, it sacrifices clarity, making it less helpful for an AI agent.

  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 (a write operation for environment variables), 0% schema coverage, no output schema, and minimal annotations, the description is incomplete. It doesn't explain what 'saveEnvironment' does operationally, what the 'env' parameter expects (e.g., key-value pairs), or what happens on success/failure. For a tool with two required parameters and mutation behavior, this leaves significant gaps for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters 'postgresId' and 'env' but provides no semantic explanation (e.g., postgresId is the identifier of the PostgreSQL instance, env is the environment variables to save). The 'any' type for 'env' is ambiguous without context. The description fails to clarify parameter meanings, leaving the agent to guess based on schema types alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[postgres] postgres.saveEnvironment (POST)' restates the tool name and HTTP method but provides minimal functional clarity. It mentions 'saveEnvironment' which implies storing environment variables, but lacks specific details about what this operation does (e.g., saves environment variables for a PostgreSQL database instance). It doesn't distinguish from sibling tools like other *_saveEnvironment tools (e.g., mariadb_saveEnvironment, redis_saveEnvironment).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing PostgreSQL instance), when-not-to-use scenarios, or related tools for environment management. Given the many sibling tools, this absence is particularly problematic for an AI agent trying to select the correct tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_searchC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover key behavioral traits (read-only, non-destructive, idempotent, open-world), so the description's burden is lower. However, it adds minimal context beyond the parameter list—no details on pagination behavior, error conditions, or what 'search' entails (e.g., partial matches, case sensitivity). It doesn't contradict annotations, but provides little extra value.

  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 brief but poorly structured—it starts with redundant API notation ('[postgres] postgres.search (GET)') and a parameter list that duplicates the schema. While not verbose, it wastes space on unhelpful formatting instead of providing meaningful content.

  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 (8 parameters, no output schema) and low schema coverage, the description is inadequate. It doesn't explain the search scope, result format, or how parameters interact. Annotations help with safety, but the description leaves critical gaps for effective tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 merely lists parameter names without explaining their meanings (e.g., what 'q' searches, how 'limit' and 'offset' work for pagination). This adds almost no semantic value beyond the schema, failing to address the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description essentially restates the tool name ('postgres.search') and lists parameters without explaining what the tool actually does. It lacks a clear verb+resource statement like 'Search for PostgreSQL databases' and doesn't distinguish this from sibling tools like 'dokploy_postgres_one' or 'dokploy_postgres_create'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, context, or comparisons with sibling tools (e.g., 'dokploy_postgres_one' for retrieving a single database). This leaves the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_previewDeployment_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds no behavioral context beyond what annotations provide, such as rate limits or authentication needs, but does not contradict them.

  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 brief but not front-loaded with useful information. It includes redundant details like '[previewDeployment]' and 'GET', while lacking substantive content. The structure is simple but inefficient in conveying necessary information.

  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 purpose (likely retrieving a preview deployment) and lack of output schema, the description is incomplete. It does not explain what a preview deployment is, what data is returned, or how it differs from other preview tools, leaving significant gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists the parameter name ('previewDeploymentId') without explaining its meaning, format, or source. This adds minimal value beyond the schema, failing to address the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('previewDeployment.one') without explaining what it does. It lacks a specific verb and resource, making it tautological. While it mentions 'GET', this is insufficient to clarify the purpose 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention sibling tools like 'dokploy_previewDeployment_all' or 'dokploy_previewDeployment_delete', leaving the agent without context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_previewDeployment_redeployC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, implying a state change, but doesn't elaborate on behavioral traits like side effects, permissions, or rate limits. With annotations covering basic safety, the description provides minimal additional context, meeting the lower bar but not enriching understanding.

  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 brief but inefficiently structured. It front-loads the tool name and method, then lists parameters without context. While not verbose, it wastes space on redundant information (e.g., restating the name) instead of providing actionable details. It could be more concise by integrating parameter explanations into the purpose statement.

  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 (a redeployment operation with 3 parameters), lack of output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what 'redeploy' entails, the outcome, error conditions, or how parameters influence the process. With annotations providing basic hints but no detailed behavioral or output information, the description leaves critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (previewDeploymentId, title, description) but doesn't explain their meanings, formats, or how they affect the redeployment. For example, it's unclear if 'title' and 'description' are for logging, notifications, or deployment metadata. This adds little value beyond the schema's structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('previewDeployment.redeploy') without explaining what 'redeploy' means in this context. It mentions 'POST' and lists parameters but doesn't specify the action's effect (e.g., restarting, updating, or triggering a new deployment of a preview deployment). This is closer to a tautology than a clear purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. Sibling tools include 'dokploy_application_redeploy' and 'dokploy_compose_redeploy', but the description doesn't differentiate this as a preview-specific redeployment or explain prerequisites. Without any usage context, the agent lacks direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redirects_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds minimal value by specifying 'GET', which aligns with read-only behavior, but does not disclose additional traits like rate limits, authentication needs, or response format. No contradiction with annotations exists, so the score reflects moderate added context.

  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 brief but poorly structured; it includes a header-like '[redirects] redirects.one (GET)' and a parameter list, but the content is under-specified rather than efficiently informative. While not verbose, it lacks clarity and front-loading of key information, making it less effective.

  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 simplicity (one parameter) and rich annotations, the description is incomplete. It lacks output schema details, does not explain the return value or behavior, and fails to provide necessary context for proper use. Annotations cover safety but not operational specifics, leaving gaps in understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'redirectId (string, required)' without explaining what a redirectId is, its format, or where to obtain it. With one parameter and no schema descriptions, the description fails to compensate for the lack of semantic information, leaving the parameter meaning unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'redirects.one (GET)' is tautological, essentially restating the tool name 'dokploy_redirects_one' without clarifying what it actually does. It mentions 'redirects' but doesn't specify the action (e.g., retrieve, fetch, get) or differentiate from sibling tools like 'dokploy_redirects_create', 'dokploy_redirects_delete', and 'dokploy_redirects_update'. The purpose remains vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 any context, prerequisites, or exclusions, nor does it refer to sibling tools for comparison. Without this information, an agent cannot determine appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redirects_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide good behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), but the description adds no context beyond what's already in annotations. It doesn't explain what 'update' entails (e.g., whether it overwrites all fields or merges, what happens to existing redirects, or any permission requirements). With annotations covering the safety profile, the description adds minimal value.

  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 concise but poorly structured. It starts with redundant bracketed text ('[redirects] redirects.update (POST)') and then provides a basic parameter list. While brief, it fails to front-load the most important information about the tool's purpose and usage.

  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 this is a mutation tool (updating redirects) with 4 parameters at 0% schema coverage and no output schema, the description is insufficient. It doesn't explain what redirects are, what fields can be updated, what the expected behavior is, or what the tool returns. The annotations help but don't compensate for the lack of semantic information in the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for explaining parameters. It only lists parameter names and types without explaining what they mean (e.g., what 'redirectId' identifies, what 'regex' pattern should match, what 'replacement' does, or what 'permanent' means for HTTP redirects). This provides almost no semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('redirects.update') and lists parameters without explaining what the tool actually does. It doesn't specify that this updates an existing redirect configuration or what 'redirects' refer to in the Dokploy context. This is essentially a tautology that provides minimal additional information 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. The sibling tools include dokploy_redirects_create, dokploy_redirects_delete, and dokploy_redirects_one, but the description doesn't differentiate this update operation from those or explain prerequisites like needing an existing redirect ID.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds minimal behavioral context by specifying it's a POST request, which aligns with the non-readOnly annotation. However, it doesn't provide any additional behavioral details like what happens on creation failure, whether it returns the created resource ID, or any side effects. The annotations cover the basic safety profile, so the description adds limited value.

  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 technically concise but poorly structured. It front-loads the tool name and method but then presents a bare parameter list without context. While there's no wasted text, the structure doesn't effectively communicate purpose or usage. The parameter list formatting is mechanical rather than informative.

  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?

  For a creation tool with 7 parameters, no output schema, and no annotations covering idempotency or side effects, the description is inadequate. It doesn't explain what gets created, what the expected output looks like, or any prerequisites. Given the complexity implied by multiple parameters and the lack of output schema, the description should provide more context about the creation operation and its results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 7 parameters (3 required), the description merely lists parameter names and types without explaining their meaning or purpose. It doesn't clarify what 'name' refers to (instance name, container name?), what 'environmentId' represents, why 'databasePassword' is required, or what 'appName' and 'serverId' are for. The description fails to compensate for the complete lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('redis.create') without explaining what it actually does. It doesn't specify what resource is being created (a Redis database instance, container, or service) or what the outcome is. While it mentions it's a POST operation, this doesn't clarify the purpose beyond the obvious implication of 'create' in 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 Guidelines1/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. With many sibling tools for different database types (mariadb_create, mysql_create, postgres_create, mongo_create) and other Redis-related tools (redis_deploy, redis_update, etc.), the description provides zero context about when this specific Redis creation tool is appropriate versus those other options.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_deployC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate it is not read-only, not destructive, not idempotent, and open-world, but the description adds no behavioral context beyond this. It implies a deployment action but does not clarify effects (e.g., whether it starts a service, applies changes, or requires specific permissions). With annotations covering basic hints, the description adds minimal value, warranting a baseline score.

  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 brief but under-specified, not efficiently conveying purpose. It includes a parameter list but lacks front-loaded clarity, making it somewhat structured but incomplete. While not verbose, it does not earn high marks due to missing essential information.

  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 (a deployment action with one parameter), annotations provide some hints, but there is no output schema and schema coverage is 0%. The description inadequately explains the tool's purpose, usage, or parameter semantics, making it incomplete for effective agent use despite the annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'redisId' as a required parameter without explaining its meaning (e.g., an identifier for a Redis configuration or instance). It fails to compensate for the lack of schema details, leaving the parameter's purpose unclear beyond its name.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[redis] redis.deploy (POST)' restates the name/title with minimal elaboration, making it tautological. It mentions 'deploy' but lacks specificity about what resource is being deployed (e.g., a Redis instance or configuration) or the outcome, failing to distinguish it from sibling tools like 'dokploy_redis_create' or 'dokploy_redis_start'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a pre-existing Redis configuration), exclusions, or related tools like 'dokploy_redis_create' for setup, leaving the agent without context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_reloadC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation with open-world semantics. The description adds minimal behavioral context by specifying it's a POST request, implying a state-changing action. However, it doesn't elaborate on what 'reload' entails operationally (e.g., service interruption, configuration refresh) or any side effects beyond what annotations imply. No contradiction with annotations exists.

  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 brief but inefficiently structured. It includes a redundant label '[redis]' and repeats the tool name, then lists parameters without explanation. While not verbose, it wastes space on unhelpful formatting rather than conveying essential information. The two-line format is simple but lacks effective front-loading of key details.

  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 has 2 parameters with 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is insufficient. It fails to explain the reload action's purpose, parameter meanings, expected outcomes, or error conditions. For a state-changing tool in a complex system with many siblings, this leaves critical gaps in understanding how to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters 'redisId' and 'appName' but provides no semantic meaning—what these identifiers represent, their format, or how they relate to the reload operation. Without this, the agent cannot understand what values to provide or their significance in the context of reloading Redis.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('redis.reload') and lists parameters without explaining what 'reload' means in this context. It doesn't specify whether this reloads configuration, restarts the service, clears cache, or performs another action. While it mentions the resource (Redis), the verb 'reload' is vague without additional context about what gets reloaded.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'dokploy_redis_start', 'dokploy_redis_stop', 'dokploy_redis_rebuild', and 'dokploy_settings_reloadRedis', there's no indication of how this tool differs or when it's appropriate. No prerequisites, timing considerations, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_saveEnvironmentC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (write operation), destructiveHint=false (non-destructive), idempotentHint=false (not idempotent), and openWorldHint=true (can create new resources). The description adds minimal behavioral context by specifying it's a POST operation, which aligns with the write nature indicated by annotations. However, it doesn't provide additional behavioral details like what happens when saving environment variables (overwrites, merges, validation), authentication requirements, or error conditions that would help an agent use it correctly beyond what annotations already indicate.

  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 extremely concise - just two lines showing the tool signature and parameter list. While this avoids verbosity, it's under-specified rather than efficiently informative. The structure is logical (tool signature then parameters) but lacks the explanatory content needed for effective tool use. Every sentence should earn its place, but here the content is too sparse to be genuinely helpful.

  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 a write operation tool (readOnlyHint=false) with 2 parameters, 0% schema description coverage, no output schema, and no behavioral annotations beyond basic hints, the description is incomplete. It doesn't explain what the tool actually does, when to use it, what the parameters mean, what the expected behavior is, or what the return value might be. For a mutation tool that saves environment variables to a Redis instance, this level of documentation is inadequate for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description lists parameters with types but adds minimal semantic value: 'redisId (string, required)' and 'env (any, required)'. It doesn't explain what redisId refers to (Redis instance ID, name, or something else), what format env should be (key-value pairs, JSON, string), or what 'any' type means in practice. For a tool with 0% schema coverage, this minimal parameter listing is insufficient compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[redis] redis.saveEnvironment (POST)' which is a tautology that restates the tool name and adds HTTP method information. It doesn't explain what 'saveEnvironment' actually does - whether it creates, updates, or persists environment variables for a Redis instance. The sibling tools list shows similar 'saveEnvironment' tools for other services (mariadb, mongo, mysql, postgres), but this description doesn't distinguish this Redis-specific version from those other database variants.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are many Redis-related sibling tools (dokploy_redis_create, dokploy_redis_update, dokploy_redis_deploy, etc.), but the description doesn't indicate when saveEnvironment is appropriate versus those other operations. No prerequisites, constraints, or alternative tools are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_registry_testRegistryC
  2.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond what's in the annotations. It doesn't explain what 'testRegistry' entails (e.g., whether it performs a network check, authentication validation, or returns specific results), nor does it mention any side effects, error conditions, or performance considerations. With annotations providing basic hints, the description fails to add meaningful behavioral details.

  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 concise but under-specified—it's essentially a header with a parameter list. While it avoids unnecessary verbosity, it lacks a clear introductory sentence explaining the tool's purpose. The structure is basic, with the tool name and HTTP method upfront, followed by a bulleted parameter list, but it doesn't effectively communicate core information.

  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 has 7 parameters with 0% schema coverage, no output schema, and annotations that only provide basic hints, the description is incomplete. It doesn't explain what the tool does, how to use it, what the parameters mean, or what to expect as a result. For a tool that likely performs a critical operation like testing a registry connection, this level of documentation is insufficient for effective use by an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 7 parameters have descriptions in the schema. The description lists parameter names and types but adds no semantic meaning (e.g., what 'registryName' represents, what 'cloud' registryType implies, or the purpose of 'imagePrefix'). This minimal listing doesn't compensate for the lack of schema documentation, leaving parameters largely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name with minimal context ('[registry] registry.testRegistry (POST)'). It doesn't specify what the tool actually does (e.g., test connectivity, validate credentials, or verify registry configuration). While it mentions 'registry' and 'POST', it lacks a clear verb and resource combination that explains the tool's function.

  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 sibling tools list includes 'dokploy_registry_testRegistryById', which appears related, but the description doesn't differentiate between them or provide any context for choosing this tool over others. No prerequisites or typical use cases are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_rollback_deleteC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: destructiveHint=true indicates deletion, readOnlyHint=false confirms it's a mutation, idempotentHint=false suggests non-idempotent behavior, and openWorldHint=true implies flexible input. The description adds no behavioral context beyond these annotations (e.g., what 'rollback' refers to, consequences of deletion, error handling). However, it does not contradict the annotations, so it meets the lower bar with annotations present.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) and lacks structured explanation. While not verbose, it under-specifies key details, making it less effective than a more informative concise description would be.

  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 destructive nature (per annotations), single parameter with 0% schema coverage, and no output schema, the description is incomplete. It does not explain the purpose, usage, or parameter semantics sufficiently for safe and correct invocation. The annotations help but don't fully compensate for the missing contextual details in the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'rollbackId' as a required string parameter but provides no semantic meaning (e.g., what a rollback ID is, where to find it, format examples). This adds minimal value beyond the schema's structural definition, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('[rollback] rollback.delete') without adding meaningful clarification. It mentions 'POST' and lists a parameter, but fails to specify what the tool actually does (e.g., delete a rollback record, remove a rollback capability). This is a tautology that provides minimal insight beyond the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 any context, prerequisites, or sibling tools (e.g., 'dokploy_rollback_rollback' from the list) that might be relevant. It lacks any usage instructions or exclusions, leaving the agent with no direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_schedule_runManuallyC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide basic hints (non-readonly, non-destructive, non-idempotent, open-world), but the description adds minimal behavioral context. The 'runManually' name implies triggering an action, and POST method suggests mutation, but the description doesn't clarify what happens (e.g., whether this executes a scheduled task immediately, returns execution results, affects schedule status). No rate limits, authentication needs, or side effects are described beyond what annotations imply.

  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 brief but under-specified rather than concise. It includes the HTTP method (POST) which is somewhat helpful, but the bracketed '[schedule]' adds little value. The parameter listing is structured but incomplete. While not verbose, it fails to convey essential information efficiently.

  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 1 parameter with 0% schema coverage, no output schema, and annotations that only provide basic hints, the description is insufficient. It doesn't explain what the tool returns, what 'runManually' entails operationally, or how it differs from other schedule tools. For a mutation tool (implied by POST) with undocumented parameters, more context about execution behavior and outcomes is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'scheduleId (string, required)' without explaining what a scheduleId is, where to find it, format expectations, or its relationship to schedules. No context about valid values or how this parameter affects the manual execution is provided, leaving significant gaps in parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[schedule] schedule.runManually (POST)' which is a tautology - it essentially repeats the tool name and adds HTTP method information. It doesn't explain what 'runManually' means in the context of schedules (e.g., triggers a scheduled task immediately, bypasses normal timing). The description fails to specify the action's effect on the schedule resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. There are sibling tools like dokploy_schedule_create, dokploy_schedule_update, and dokploy_schedule_list, but the description doesn't indicate this is for manual triggering versus automated scheduling or other schedule operations. No prerequisites, conditions, or alternatives are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_schedule_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), but the description adds no behavioral context beyond what's in the annotations. It doesn't explain what 'update' entails (e.g., partial vs. full updates, side effects, or error handling). With annotations covering safety and idempotency, the description adds minimal value, scoring a baseline 3.

  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 structured as a parameter list, which is somewhat organized but not front-loaded with a clear purpose statement. It includes unnecessary details like '[schedule] schedule.update (POST)' without adding value, making it verbose in a way that doesn't aid comprehension. However, it avoids excessive fluff, keeping it moderately concise.

  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 (16 parameters, 4 required), low schema coverage (0%), no output schema, and annotations that only cover basic hints, the description is incomplete. It fails to explain the tool's behavior, parameter interactions, or expected outcomes, making it inadequate for an AI agent to use this tool effectively in context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists parameter names and types without explaining their meanings or relationships. For example, it doesn't clarify how 'scheduleType' relates to 'applicationId', 'composeId', etc., or what 'cronExpression' format is expected. This leaves significant gaps in understanding the 16 parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name 'schedule.update' without providing meaningful context about what the tool actually does. It lists parameters but doesn't explain the purpose beyond the name, making it vague for an AI agent trying to understand when to use this tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 like 'dokploy_schedule_create' or 'dokploy_schedule_delete' from the sibling list. The description lacks any context about prerequisites, typical use cases, or exclusions, leaving the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_security_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a write operation (readOnlyHint=false), non-destructive, non-idempotent, and open-world. The description adds no behavioral context beyond what annotations provide—it doesn't explain what 'security.create' entails (e.g., whether it creates user credentials, what permissions are needed, if it sends notifications, or what happens on conflict). However, it doesn't contradict annotations, so it meets the lower bar with annotations present but adds minimal value.

  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 brief but not front-loaded with purpose; it starts with a tautological label and a parameter list. The two-line structure is efficient, but the content is under-specified rather than concise—it wastes space on obvious details (POST method, parameter names) instead of explaining the tool's function. It could be more effectively structured with a clear purpose statement first.

  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 (a write operation with 3 parameters, no output schema, and annotations covering basic hints), the description is incomplete. It lacks essential context: what security entity is created, what the parameters mean, expected outcomes, error conditions, or relation to sibling tools. For a create operation in a security context, this leaves significant gaps for an AI agent to infer correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameter names (applicationId, username, password) but provides no semantic meaning—what these parameters represent, their format constraints (e.g., username rules, password complexity), or how they relate to the security object being created. This adds little value beyond the schema's type and required information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'security.create (POST)' which is a tautology of the tool name and HTTP method, and lists parameters without explaining what the tool actually does. It doesn't specify what kind of security object is being created (e.g., user account, authentication credential, security policy) or what resource is affected. The verb 'create' is generic and doesn't distinguish this from other 'create' tools in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like dokploy_security_delete, dokploy_security_one, and dokploy_security_update, but the description doesn't explain how this create operation relates to them or when it's appropriate. No prerequisites, context, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_security_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide comprehensive behavioral information: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds minimal value beyond this - it confirms the HTTP method is GET (which aligns with readOnlyHint) but doesn't provide any additional behavioral context about what specifically gets retrieved, potential side effects, authentication requirements, or rate limits. With good annotation coverage, the description meets the lower bar but doesn't add meaningful behavioral insight.

  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 extremely concise - just one line plus a parameter listing. However, this conciseness comes at the cost of being under-specified rather than efficient. The structure is basic but functional, with the HTTP method and parameter name clearly indicated. While not verbose, it lacks the substance needed to be truly helpful, making this borderline between adequate and inadequate.

  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 that this is a read operation (GET) with good annotation coverage but no output schema, the description should explain what kind of data is returned. It doesn't specify whether this returns security settings, logs, policies, or other security-related information. With 0% schema description coverage for the required parameter and no output schema, the description leaves too many unanswered questions about what this tool actually does and what results to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 0%, meaning the schema provides no documentation for the single required parameter 'securityId'. The description only lists the parameter name without explaining what a securityId is, what format it should be in, where to find valid securityIds, or what happens if an invalid securityId is provided. For a tool with one required parameter and zero schema documentation, the description fails to compensate adequately for the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[security] security.one (GET)' which is tautological - it essentially repeats the tool name 'dokploy_security_one' and adds the HTTP method. It doesn't explain what the tool actually does (retrieve security information? get a specific security setting? view security logs?). The description fails to provide a clear verb+resource combination that distinguishes this from sibling tools like dokploy_security_create, dokploy_security_delete, or dokploy_security_update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention what security information this retrieves, when you'd want to get security data versus create/update/delete it, or how this relates to other security-related tools in the system. With multiple sibling security tools available, this lack of differentiation guidance is a significant gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds no behavioral context beyond what annotations already cover (e.g., no rate limits, auth needs, or return format). However, it does not contradict annotations, so it meets the baseline for having annotations but adds minimal extra value.

  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 concise with two lines, but it is poorly structured and under-specified. The first line '[server] server.one (GET)' is cryptic, and the parameter listing is minimal. While it avoids verbosity, it lacks clarity and effective front-loading of key information, making it less helpful than it could be.

  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 has 1 parameter with 0% schema coverage, no output schema, and annotations covering safety, the description is incomplete. It fails to explain what the tool returns, how to interpret results, or provide essential context for a read operation. This leaves significant gaps for an agent to understand and use the tool effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists 'serverId (string, required)' but adds no semantic meaning (e.g., what a serverId is, format examples, where to find it). This partially compensates by naming the parameter but fails to provide meaningful context, resulting in inadequate documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[server] server.one (GET)' is vague and tautological. It repeats the tool name 'server.one' without specifying what the tool actually does (e.g., retrieve server details, fetch server configuration). It mentions 'GET' which indicates an HTTP method but doesn't clarify the action or resource purpose. This provides minimal clarity beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for usage, or differentiate it from sibling tools like 'dokploy_server_all' or 'dokploy_server_getServerMetrics'. Without such information, an agent cannot determine appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_setupC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds no behavioral context beyond these annotations, such as what 'setup' entails, potential side effects, or execution details. It doesn't contradict annotations, but offers no additional value.

  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 extremely concise with minimal waste, consisting of a single line. However, it lacks structure and front-loading of key information, as it doesn't clearly state the tool's purpose upfront. It's efficient but under-specified rather than optimally structured.

  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 likely complexity (a setup operation with no output schema), the description is inadequate. It doesn't explain what 'setup' does, expected outcomes, or error conditions. With annotations covering basic hints but no behavioral details, the description fails to provide a complete picture for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the undocumented parameter 'serverId'. The description provides no information about what 'serverId' is, its format, where to obtain it, or its role in the setup process. It fails to add any semantic meaning beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[server] server.setup (POST)' is a tautology that restates the name and title without adding meaningful context. It mentions 'server.setup' which is essentially the tool name, and 'POST' which is implied by the absence of readOnlyHint. No specific verb or resource is clarified beyond what's already obvious from the naming.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. With many sibling tools like 'dokploy_server_setupMonitoring' and 'dokploy_server_create', the description fails to differentiate this tool's specific use case, prerequisites, or exclusions. It provides no context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_setupMonitoringC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide structured hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), which inform the agent this is a non-destructive, idempotent write operation that may create new resources. The description adds no behavioral context beyond what annotations already cover, such as side effects, permissions needed, or rate limits. However, it does not contradict annotations, so it meets the baseline for when annotations are present.

  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 brief and front-loaded with the tool signature, but it is under-specified rather than concise. It wastes space on formatting (brackets, dashes) without adding value. While not verbose, it lacks essential information, making it inefficient in conveying purpose or usage.

  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 (2 parameters with nested objects, no output schema, and annotations covering basic hints), the description is incomplete. It does not explain what 'setupMonitoring' entails, what the 'metricsConfig' object configures, or what the tool returns. For a configuration tool with significant parameter complexity, this leaves the agent poorly equipped to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description only lists parameter names ('serverId', 'metricsConfig') without explaining their purpose, expected values, or relationships. For a complex nested object like 'metricsConfig' with many sub-properties, this lack of semantic explanation is a significant gap, failing to compensate for the schema's deficiency.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('server.setupMonitoring') without adding meaningful context about what the tool actually does. It provides a verb ('setupMonitoring') but lacks specificity about what monitoring entails, what resources are affected, or how it differs from sibling tools like 'dokploy_server_getServerMetrics' or 'dokploy_application_readAppMonitoring'. This is essentially a tautology of the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to monitoring, metrics, and server configuration, there is no indication of prerequisites, appropriate contexts, or distinctions from similar tools. The agent receives no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide good behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description's burden is lower. The description doesn't contradict these annotations, but adds minimal value beyond them—it doesn't explain what 'update' entails (e.g., partial vs. full updates, validation behavior, or side effects). No additional context like auth needs or rate limits is provided.

  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 brief but poorly structured—it starts with a tautological header, then dumps a parameter list without grouping or prioritization. While not verbose, it fails to front-load key information (the tool's purpose) and includes parameter details that belong in the schema, making it inefficient.

  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 (9 parameters, 8 required, mutation tool), lack of output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain the update operation's scope, expected inputs, or what happens on success/failure. Annotations help, but the description leaves critical gaps for a tool with many parameters and no output documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 merely lists parameter names and types without explaining their meaning, constraints, or relationships (e.g., what serverId refers to, how ipAddress/port relate to connectivity, what serverType 'deploy' vs. 'build' implies, or what command does). This adds little semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name as '[server] server.update (POST)' which is tautological, then lists parameters without explaining what the tool actually does. It doesn't specify what resource is being updated (a server configuration), what 'update' means operationally, or how it differs from sibling tools like dokploy_server_create or dokploy_server_remove.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. With many sibling tools (including dokploy_server_create, dokploy_server_remove, dokploy_server_one, and dokploy_server_all), the description offers no context about prerequisites, when updates are appropriate, or what distinguishes this from other server operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_assignDomainServerC
  2.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable operation (readOnlyHint=false) but not destructive or idempotent. The description adds no behavioral context beyond what annotations provide - no information about what gets configured, whether this affects existing domains, what permissions are required, or what the expected outcome is. For a configuration tool with openWorldHint=true, more context about system impact would be helpful.

  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 brief but inefficiently structured. It wastes space repeating '[settings] settings.assignDomainServer' and '(POST)' while providing minimal useful information. The parameter listing is better placed in the schema. However, it's not excessively 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?

  For a configuration tool with 4 parameters, 0% schema description coverage, no output schema, and annotations that only cover basic safety hints, the description is inadequate. It doesn't explain what this tool actually accomplishes, what system components it affects, what the expected outcome is, or provide any meaningful parameter guidance.

  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 description lists parameters with basic types but provides no semantic meaning. With 0% schema description coverage, the description doesn't compensate by explaining what 'host' represents, what the certificateType options mean in practice, when letsEncryptEmail is needed, or what the https flag controls. It merely repeats parameter names already visible in the schema without adding value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name/title ('settings.assignDomainServer') and adds '(POST)' which is redundant with HTTP method. It doesn't explain what 'assignDomainServer' actually does - whether it configures domain settings, associates a domain with a server, or performs some other operation. The purpose remains vague 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. With many sibling tools in the settings category (like dokploy_settings_updateServer, dokploy_settings_updateTraefikConfig, etc.), there's no indication of when domain server assignment is appropriate versus other configuration operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_checkGPUStatusC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints (readOnly, non-destructive, idempotent, openWorld), so the description's burden is lower. The description adds that this is a GET operation, which aligns with readOnlyHint=true. However, it doesn't provide any additional behavioral context such as what 'GPU status' entails, whether authentication is required, potential rate limits, or error conditions. The description doesn't contradict annotations, but adds minimal value beyond them.

  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 extremely brief (effectively one line plus a parameter list), which could be seen as concise. However, it's structured poorly with bracketed text '[settings]' and mixes HTTP method notation with parameter documentation in a non-standard format. While not verbose, it lacks clear organization and front-loading of key information.

  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 GPU status checking (which could involve hardware detection, driver status, utilization metrics) and the absence of an output schema, the description is severely incomplete. It doesn't explain what 'GPU status' means, what information is returned, or how to interpret results. The annotations help with safety profile, but the functional purpose remains opaque.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'serverId (string, optional)' but provides no semantic context about what this parameter means, what values are valid, or how it affects the GPU status check. Without this information, the agent cannot understand when or why to provide a serverId versus leaving it unspecified.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('settings.checkGPUStatus') without explaining what 'checkGPUStatus' actually does. It mentions 'GET' which indicates an HTTP method but doesn't clarify what resource is being checked or what information is returned. This is essentially a tautology that provides minimal additional insight 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools related to settings, servers, and monitoring (like 'dokploy_settings_setupGPU', 'dokploy_server_getServerMetrics', 'dokploy_settings_getUpdateData'), there's no indication of when this specific GPU status check is appropriate or what distinguishes it from other monitoring tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanAllC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. However, the description adds minimal behavioral context beyond annotations—it doesn't specify what gets cleaned, potential side effects, or prerequisites. With annotations covering safety, a baseline 3 is appropriate, but the description could enhance understanding.

  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 brief but poorly structured—it mixes endpoint notation ('[settings] settings.cleanAll (POST)') with a parameter list without clear separation. While concise, it lacks effective front-loading of key information, making it less helpful for quick understanding.

  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 destructive nature (per annotations), no output schema, and 0% schema coverage, the description is inadequate. It doesn't explain what 'cleanAll' does, what is affected, or the expected outcome, leaving significant gaps for a potentially high-impact operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'serverId (string, optional)' without explaining its purpose, format, or impact. This fails to add meaningful semantics beyond the bare schema, leaving the parameter's role unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('settings.cleanAll') without explaining what 'cleanAll' means. It mentions 'POST' and lists a parameter, but doesn't specify what resource is being cleaned or what 'clean' entails. This is a tautology that adds little beyond the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., dokploy_settings_cleanAllDeploymentQueue, dokploy_settings_cleanDockerPrune), the description fails to differentiate this tool's specific use case or context, leaving the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanDockerPruneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations clearly indicate this is a destructive (destructiveHint: true), non-idempotent (idempotentHint: false) write operation (readOnlyHint: false). The description adds minimal value beyond this - it confirms it's a POST request, which aligns with the write operation indicated by annotations. However, it doesn't provide additional behavioral context such as what specifically gets pruned, whether there are confirmation prompts, what permissions are required, or what the typical response looks like. No contradiction with annotations exists.

  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 extremely concise - arguably too concise. While it wastes no words, it's under-specified rather than efficiently informative. The structure shows the endpoint path and HTTP method, which is somewhat useful, but lacks any explanatory content about the tool's purpose or usage. It's front-loaded with minimal information but fails to provide the essential context an agent needs.

  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?

  For a destructive Docker management tool with no output schema and 0% parameter documentation, this description is severely incomplete. The annotations provide safety warnings, but the description doesn't explain what Docker resources are affected, what 'prune' means in this context, or what the consequences of invocation are. Given the complexity implied by 'DockerPrune' and the complete lack of parameter documentation, this description leaves critical gaps for an agent trying to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage for the single parameter (serverId), the description provides no information about this parameter. The description doesn't explain what serverId represents, whether it's required or optional (though schema shows optional), what format it should be in, or how to obtain valid server IDs. For a tool with undocumented parameters, the description fails to compensate for the schema's lack of documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.cleanDockerPrune (POST)' is tautological, essentially restating the tool name and title with minimal added meaning. It mentions 'POST' which indicates an HTTP method but doesn't explain what 'cleanDockerPrune' actually does - whether it prunes Docker images, containers, volumes, or all of the above. The description fails to provide a clear verb+resource combination that distinguishes this tool from its many siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools in the Dokploy system (including other 'clean' operations like cleanAll, cleanUnusedImages, cleanUnusedVolumes, cleanStoppedContainers), the agent receives no indication of what specific Docker pruning this performs or when it's appropriate to use. There's no mention of prerequisites, timing considerations, or alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanStoppedContainersC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide significant behavioral information: destructiveHint=true indicates this performs destructive operations, readOnlyHint=false confirms it's a mutation, idempotentHint=false suggests non-idempotent behavior, and openWorldHint=true implies it may affect external resources. The description adds no behavioral context beyond what annotations already declare. However, it doesn't contradict annotations (e.g., it doesn't claim to be read-only while annotations say readOnlyHint=false), so it avoids a contradiction penalty. With annotations covering key traits, the bar is lower, but the description adds no value.

  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 brief but inefficiently structured. It includes redundant information like '[settings]' and '(POST)' that don't add clarity, while missing essential explanatory content. The parameter listing is presented but lacks meaningful context. While not verbose, it's under-specified rather than concise, with sentences that don't earn their place through useful information.

  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 (destructive operation with annotations), 0% schema description coverage, no output schema, and a single parameter, the description is incomplete. It fails to explain what 'clean' entails, what 'stopped containers' are, the impact of the operation, or expected outcomes. Annotations provide safety warnings, but the description doesn't supplement with practical context needed for an agent to use this tool effectively in a deployment environment.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'serverId (string, optional)' as a parameter, which matches the input schema. However, schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description adds minimal semantics by naming the parameter but doesn't explain what 'serverId' represents, why it's optional, or what happens if omitted. For a single parameter with 0% schema coverage, the description should compensate more substantially with contextual meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('settings.cleanStoppedContainers') and adds '(POST)' but doesn't explain what the tool actually does. It doesn't specify what 'clean' means (e.g., delete, remove, prune) or what 'stopped containers' refers to. While it mentions 'settings', this is tautological with the name and doesn't provide a clear verb+resource action. Compared to siblings like 'dokploy_settings_cleanAll' or 'dokploy_settings_cleanUnusedImages', it doesn't distinguish its specific purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or related tools. Given the many sibling tools with 'clean' in their names (e.g., 'dokploy_settings_cleanAll', 'dokploy_settings_cleanUnusedImages'), there's no indication of when this specific container-cleaning tool is appropriate versus other cleanup operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_haveTraefikDashboardPortEnabledC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints (readOnly, non-destructive, idempotent, openWorld), but the description adds minimal value by specifying it's a GET operation, which aligns with readOnlyHint. However, it does not disclose additional behavioral traits like rate limits, authentication needs, or what the output indicates (e.g., boolean status). With annotations covering safety, a baseline score is appropriate, though more context could enhance transparency.

  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 brief but under-specified, not truly concise. It includes the tool path and '(GET)' which is somewhat front-loaded, but the parameter listing is minimal and lacks useful information. While not verbose, it does not efficiently convey necessary details, making it mediocre in structure.

  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 checking a Traefik dashboard port status, the description is incomplete. No output schema exists, and the description does not explain return values (e.g., boolean indicating enabled/disabled). With annotations providing safety hints but no behavioral context, the description fails to offer a comprehensive understanding for effective tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only defines 'serverId' as an optional string without descriptions. The tool description lists 'serverId' but provides no semantic meaning, such as what a serverId represents or how it affects the query. This fails to compensate for the low coverage, leaving parameter purpose unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('settings.haveTraefikDashboardPortEnabled') with '(GET)' appended, which is a tautology. It does not explain what the tool does beyond indicating it's a GET operation. No specific verb or resource clarification is provided, making it vague and unhelpful for distinguishing its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 lacks any context about its application, prerequisites, or exclusions. Given the many sibling tools, this omission leaves the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_readDirectoriesC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already indicate safe, repeatable operations. The description adds minimal behavioral context by specifying 'GET', implying a read operation, but doesn't disclose additional traits like what data is returned, error conditions, or rate limits. With annotations covering the safety profile, a baseline score is appropriate.

  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 brief but poorly structured. It includes a parameter list that is redundant with the schema and lacks a clear, front-loaded purpose statement. While not verbose, it doesn't efficiently convey necessary information, making it less helpful than it could be.

  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 lack of output schema and low parameter coverage, the description is incomplete. It doesn't explain what 'directories' are being read, the format of the output, or any dependencies. For a tool with one parameter and no output schema, more context is needed to guide effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'serverId (string, optional)' but doesn't explain what a serverId is, how to obtain it, or what effect omitting it has (e.g., defaults to current server). This adds minimal meaning beyond the schema's type information, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('settings.readDirectories') without explaining what it actually does. It mentions 'GET' and lists a parameter, but doesn't specify what directories are being read (e.g., server directories, configuration directories) or what the purpose of reading them is. This is closer to tautology than a clear purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 doesn't mention any context, prerequisites, or related tools (like other 'settings' or 'read' tools in the sibling list). Without this, an agent cannot determine appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_reloadTraefikC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request to reload Traefik, which implies a state-changing operation that likely causes Traefik to reload its configuration. This provides useful context beyond annotations about what gets reloaded, though it doesn't specify potential side effects like service interruption or authentication requirements.

  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 extremely concise at just two lines, but this brevity comes at the cost of completeness. The structure shows the endpoint path and HTTP method upfront, which is useful, but the parameter listing lacks explanatory value. While not verbose, it's arguably under-specified rather than efficiently informative.

  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?

  For a tool that performs a potentially impactful operation (reloading Traefik configuration) with no output schema, the description is inadequate. It doesn't explain what 'reload' entails, what gets reloaded, potential side effects, success/failure indicators, or relationship to other Traefik tools. Given the complexity of configuration management and the absence of output documentation, more context is needed for safe usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description mentions 'Parameters: - serverId (string, optional)' but provides no semantic meaning for this parameter. With 0% schema description coverage, the description fails to explain what serverId refers to, whether it's required in certain contexts, or what happens if omitted. It simply repeats the parameter name without adding meaningful context beyond what's in the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[settings] settings.reloadTraefik (POST)' which is a tautology that essentially restates the tool name with minimal additional context. It mentions 'reloadTraefik' which suggests reloading Traefik configuration, but doesn't specify what resource is being acted upon or what the tool actually does beyond the name. It doesn't distinguish from sibling tools like 'dokploy_settings_reloadServer' or 'dokploy_settings_reloadRedis'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are multiple reload-related tools in the sibling list (reloadServer, reloadRedis) and many Traefik-related tools (readTraefikConfig, updateTraefikConfig, etc.), but the description offers no context about when this specific reload operation is appropriate versus other configuration management tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateLogCleanupC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key behavioral hints: destructiveHint=true (changes system state), idempotentHint=true (safe to retry), openWorldHint=true (may accept unknown values). The description adds no additional context beyond these annotations, such as what gets cleaned up, potential side effects, or rate limits. However, it does not contradict the annotations, so it meets the lower bar with annotations present.

  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 brief but not front-loaded with key information; it starts with redundant details like '[settings]' and HTTP method. It includes a parameter list, which is somewhat structured, but overall it lacks efficiency and could be more streamlined to convey essential details without waste.

  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 (destructive mutation with one parameter), no output schema, and low schema coverage, the description is incomplete. It fails to explain the tool's effect (e.g., what log cleanup entails), expected outcomes, or error conditions. With annotations covering safety but not operational details, more context is needed for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists 'cronExpression (any, required)' but does not explain its purpose (e.g., cron schedule for log cleanup), format (e.g., cron syntax examples), or valid values (e.g., null to disable). It adds minimal meaning beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('settings.updateLogCleanup') and HTTP method ('POST'), which is tautological. It does not specify what the tool actually does (e.g., update log cleanup settings, configure a cron job for log cleanup) or distinguish it from sibling tools like 'dokploy_settings_getLogCleanupStatus' or other settings tools. The purpose is vague 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 Guidelines1/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. It does not mention prerequisites (e.g., needing admin permissions), related tools (e.g., 'dokploy_settings_getLogCleanupStatus' for checking status), or scenarios for use. The description lacks any usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateMiddlewareTraefikConfigC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover key behavioral traits. The description adds no additional context beyond these annotations, such as rate limits, authentication needs, or side effects. Since annotations are comprehensive, the bar is lower, but the description fails to add any value beyond them.

  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 brief but poorly structured. It includes redundant information (tool name and parameter listing) without front-loading key details. While not verbose, it lacks efficiency as it fails to convey useful information beyond what's already obvious from structured fields.

  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 (updating middleware Traefik config), lack of output schema, and 0% schema description coverage, the description is inadequate. It does not explain what the tool does, its impact, or expected outcomes, leaving significant gaps for the agent to understand its use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'traefikConfig (string, required)', which mirrors the schema without explaining what this parameter represents (e.g., configuration format, content, or purpose). No semantic details are provided, leaving the parameter meaning unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title without adding meaningful context. It mentions 'settings.updateMiddlewareTraefikConfig (POST)' which is tautological, and 'Parameters: - traefikConfig (string, required)' merely repeats schema information. No specific verb or resource clarification is provided beyond what's already in 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 Guidelines1/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 any context, prerequisites, or sibling tools (e.g., dokploy_settings_readMiddlewareTraefikConfig or other Traefik-related tools), leaving the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateServerIpC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds minimal behavioral context beyond what annotations provide. Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, idempotent, open-world operation. The description only confirms it's a POST request, which aligns with the mutable nature. However, it doesn't add important context like what happens when the server IP is updated (does it affect running services? require restart?), authentication requirements, or rate limits. No contradiction with annotations exists.

  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 extremely concise - arguably too concise. It's structured with a title-like format and parameter listing, but lacks complete sentences explaining functionality. While not verbose, it under-specifies rather than being efficiently informative. The parameter listing is helpful but the overall description feels incomplete rather than optimally concise.

  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 this is a mutation tool (updating server IP) with no output schema, the description is inadequate. It doesn't explain what the tool returns, what side effects occur, error conditions, or how this interacts with the broader system. With annotations covering basic safety but no output schema, the description should provide more context about the operation's impact and results. The sibling tools show this is part of a complex settings management system, but the description doesn't situate it within that context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 1 required parameter, the description provides minimal parameter semantics. It lists 'serverIp (string, required)' but doesn't explain what format the IP should be (IPv4, IPv6), whether it's a validation pattern, what this IP represents (public IP, internal IP, management IP), or provide examples. The schema only indicates it's a string type, so the description adds little value beyond repeating the parameter name.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name and HTTP method ('settings.updateServerIp (POST)') but is tautological - it essentially repeats the tool name. It doesn't explain what 'updateServerIp' actually does in terms of functionality or what resource is being modified. While it mentions 'settings', it doesn't clarify if this updates global settings, server settings, or something else.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. With many sibling tools in the dokploy_settings_* namespace (like dokploy_settings_updateServer, dokploy_settings_getIp, etc.), there's no indication of when this specific server IP update tool should be used versus other server-related settings tools. No prerequisites, dependencies, or context is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateTraefikConfigC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (indicating mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (flexible input). The description adds no behavioral context beyond these annotations—it doesn't explain what 'update' entails (e.g., overwrites, merges), potential side effects, authentication needs, or rate limits. With annotations covering basic safety, the description adds minimal value, but doesn't contradict them, so a baseline 3 is appropriate.

  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 brief and front-loaded with the tool signature, but it includes redundant information (e.g., '[settings]' prefix and '(POST)') that doesn't add value. The parameter listing is minimal but could be more integrated. While not verbose, it lacks efficiency in conveying essential information, making it adequate but with room for improvement in structure and clarity.

  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 a mutation tool with annotations but no output schema and 0% schema description coverage, the description is incomplete. It doesn't explain the purpose, usage, or parameter meaning sufficiently. The annotations help with behavioral hints, but the description fails to provide necessary context for safe and correct invocation, such as what the tool updates, expected input format, or implications of the update.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists 'traefikConfig (string, required)' but doesn't explain what this parameter represents (e.g., YAML/JSON configuration content, file path, specific settings). It adds minimal semantics beyond the schema's type and requirement, failing to compensate for the lack of schema documentation, especially for a mutation tool with a single but likely complex parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[settings] settings.updateTraefikConfig (POST)' which is essentially a restatement of the tool name and title with the addition of 'POST'. It doesn't clearly articulate what the tool actually does (e.g., update Traefik configuration for what system/component, with what effect). While it mentions 'TraefikConfig', it lacks a specific verb-resource combination that distinguishes it from sibling tools like 'dokploy_settings_updateWebServerTraefikConfig' or 'dokploy_settings_updateMiddlewareTraefikConfig'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions. Given the presence of sibling tools like 'dokploy_settings_readTraefikConfig' and other update variants, there is no indication of when this specific update tool is appropriate, leading to potential confusion for an AI agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateTraefikFileC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (write operation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (supports unknown inputs). The description adds no behavioral context beyond these annotations—it doesn't explain what 'update' entails (e.g., overwrites file, merges configs, requires specific permissions), potential side effects, or error conditions. With annotations covering safety and idempotency, the bar is lower, but the description adds no value beyond the structured data.

  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 brief but not well-structured—it starts with a redundant '[settings] settings.updateTraefikFile (POST)' and follows with a basic parameter list. While concise, it lacks front-loaded purpose and wastes space on obvious details (POST method). The parameter list is clear but could be integrated into a more informative sentence.

  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 3 parameters with 0% schema coverage, no output schema, and annotations that only cover safety/idempotency, the description is incomplete. It fails to explain the tool's purpose, parameter meanings, usage context, or expected outcomes. For a write operation (update) in a complex system with many sibling tools, this leaves significant gaps for an AI agent to infer correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters (path, traefikConfig, serverId) with types and required status, but adds minimal semantics—it doesn't explain what 'path' refers to (file path? URL path?), what format 'traefikConfig' expects (YAML? JSON?), or when 'serverId' is needed. For a tool with 3 parameters and 0% schema coverage, this is insufficient compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name with minimal context: '[settings] settings.updateTraefikFile (POST)' essentially repeats the name and adds HTTP method. It lacks a clear verb+resource statement explaining what 'updateTraefikFile' actually does—does it modify, replace, or create a Traefik configuration file? No sibling differentiation is provided despite many related Traefik tools in the sibling list (e.g., dokploy_settings_readTraefikFile, dokploy_settings_updateTraefikConfig).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 versus alternatives. The sibling list includes dokploy_settings_readTraefikFile, dokploy_settings_updateTraefikConfig, and dokploy_settings_writeTraefikEnv, but the description does not mention any of these or provide context for choosing this tool over others. There are no prerequisites, exclusions, or usage scenarios described.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sshKey_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive (destructiveHint=false), non-idempotent (idempotentHint=false), open-world (openWorldHint=true) operation. The description adds no behavioral context beyond the implied 'create' action. It doesn't disclose authentication needs, rate limits, what happens on duplicate names, or the response format. With annotations covering basic safety, the description adds minimal value, scoring a baseline 3.

  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 brief but poorly structured. It front-loads with '[sshKey] sshKey.create (POST)' which is redundant, then lists parameters without context. While concise, it wastes space on obvious information (POST method) instead of explaining purpose. The parameter list is clear but could be integrated into a more informative sentence.

  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 a creation tool with 5 parameters (4 required), 0% schema coverage, no output schema, and annotations only covering basic hints, the description is incomplete. It lacks purpose, usage guidelines, parameter meanings, and behavioral details like response structure or error conditions. For a tool that creates security-sensitive resources (SSH keys), this leaves significant gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides only types and constraints without meaning. The description lists parameter names but adds no semantics (e.g., 'name' for the SSH key identifier, 'privateKey/publicKey' as the key pair, 'organizationId' to associate the key). It doesn't explain formats (e.g., PEM for keys) or dependencies. For 5 parameters with 0% coverage, this is inadequate compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'sshKey.create (POST)' which is a tautology of the tool name and HTTP method, not a clear purpose. It lists parameters but doesn't explain what the tool actually does (creates an SSH key resource). While it distinguishes from siblings like 'sshKey_all' or 'sshKey_remove' by implying creation, it lacks a specific verb-resource statement like 'Creates a new SSH key in the Dokploy system'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an organizationId), when not to use it (e.g., for existing keys), or refer to sibling tools like 'sshKey_generate' (for auto-generating keys) or 'sshKey_update' (for modifying keys). The agent must infer usage from the parameter list alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sso_oneC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, non-destructive, repeatable operation that may return partial data. The description adds minimal context by specifying 'GET', but it doesn't disclose additional behavioral traits like error conditions, authentication needs, or rate limits. Since annotations cover the safety profile, the description's limited addition justifies a baseline score.

  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 brief and front-loaded with the tool name and HTTP method, but it includes a redundant parameter listing that adds little value. It could be more concise by integrating parameter details meaningfully. However, it avoids unnecessary verbosity and is structured clearly.

  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 has one parameter with 0% schema coverage, no output schema, and annotations that cover basic safety, the description is incomplete. It doesn't explain the purpose, usage, or parameter meaning adequately, making it insufficient for an agent to understand how to invoke the tool correctly or interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for the single parameter 'providerId'. The description only lists 'providerId (string, required)' without explaining what it represents (e.g., an identifier for an SSO provider), its format, or examples. This fails to compensate for the lack of schema documentation, leaving the parameter's meaning unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[sso] sso.one (GET)' which partially indicates it's a GET operation related to SSO, but it's vague about what it actually retrieves (e.g., a specific SSO provider configuration). It doesn't clearly distinguish from sibling tools like 'dokploy_sso_listProviders' or 'dokploy_sso_update', leaving the agent uncertain about the exact resource and action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 lacks any mention of context, prerequisites, or comparisons to sibling tools such as 'dokploy_sso_listProviders' (which might list multiple providers) or 'dokploy_sso_update' (which modifies providers). This absence makes it difficult for an agent to decide when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sso_updateTrustedOriginC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), covering safety and idempotency. The description adds minimal context by implying a POST operation for updating, but doesn't disclose additional traits like error conditions, authentication needs, or rate limits. It doesn't contradict annotations, so it meets the lower bar with annotations present.

  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 brief and front-loaded with the tool name, but includes redundant information (repeating the name) and lacks structure. It could be more efficient by omitting the tautological part and focusing on meaningful content. However, it's not overly verbose, just under-specified.

  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 (mutation operation with 2 parameters), lack of output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the purpose, usage, or parameter meanings sufficiently. Annotations help but don't fully compensate for the missing contextual details needed for effective tool invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (oldOrigin, newOrigin) but only states they are required strings without explaining what they represent (e.g., URLs, identifiers) or their format. This adds little semantic value beyond the schema, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title without adding meaningful clarification. It mentions 'sso.updateTrustedOrigin (POST)' which is essentially a tautology of the name, and lists parameters but doesn't explain what the tool actually does—like updating a trusted origin in an SSO context. It fails to distinguish from sibling tools like dokploy_sso_addTrustedOrigin or dokploy_sso_removeTrustedOrigin.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. It doesn't mention prerequisites, context, or exclusions, leaving the agent with no usage direction. Sibling tools like dokploy_sso_addTrustedOrigin and dokploy_sso_removeTrustedOrigin exist, but the description provides no comparison or selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_getBackupsC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide comprehensive behavioral information (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true). The description adds minimal value by indicating this is a GET operation, which aligns with the read-only annotation. However, it doesn't provide any additional behavioral context such as what permissions are required, what format the backups are returned in, or whether there are any rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While the description is extremely brief, this is under-specification rather than effective conciseness. The single bracketed phrase '[user] user.getBackups (GET)' doesn't form a complete sentence or provide meaningful information. True conciseness would efficiently convey purpose and usage, but this is simply inadequate.

  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?

  For a tool with no output schema and no parameters, the description should at minimum explain what the tool returns and its purpose. The annotations provide good behavioral coverage, but the description fails to explain what 'backups' are in this context, what scope they cover, or what format they're returned in. Given the complexity implied by the sibling tools, this is insufficient.

  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 parameters and 100% schema description coverage, the schema fully documents that no inputs are required. The description doesn't need to add parameter information, and it doesn't attempt to describe nonexistent parameters. The baseline for zero parameters with full schema coverage is 4, as there's nothing additional needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose1/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.getBackups (GET)' is essentially a tautology that restates the tool name and HTTP method without explaining what the tool actually does. It doesn't specify what 'backups' refers to, what resource is being accessed, or what the operation accomplishes. This provides no meaningful guidance beyond what's already in 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include dokploy_backup_listBackupFiles and dokploy_volumeBackups_list, there are clearly related backup listing tools, but the description offers no differentiation or context about when this specific user-focused backup retrieval tool should be selected.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_getContainerMetricsC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover the core safety and idempotency profile. The description adds no behavioral context beyond what annotations provide - no information about rate limits, authentication requirements (though 'token' parameter implies auth), what happens if containers don't exist, or what format the metrics are returned in. However, it doesn't contradict the annotations, so it meets the lower bar when annotations are present.

  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 concise but under-specified rather than efficiently informative. The parameter listing is structured but lacks explanatory value. While it doesn't waste words, it also doesn't provide sufficient information - every sentence (or line) should earn its place by adding meaningful context, which this doesn't achieve.

  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?

  For a tool with 4 required parameters, 0% schema description coverage, no output schema, and no annotations that explain parameter semantics, the description is severely incomplete. It doesn't explain what the tool returns, what the parameters mean, when to use it, or how it differs from similar tools. The annotations provide safety information but don't compensate for the missing operational context needed to effectively use this metrics retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 4 required parameters, the description carries significant burden to explain parameter meaning. It merely lists parameter names and types without any semantic explanation - what 'url' should point to, what kind of 'token' is needed, what 'appName' represents, or what 'dataPoints' should contain (metrics to retrieve, time range, etc.). This provides minimal value beyond the schema's structural information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name with minimal context. It states '[user] user.getContainerMetrics (GET)' which repeats the name and adds the HTTP method, but doesn't explain what 'getContainerMetrics' actually does - what metrics are retrieved, from what system, or what the output represents. It fails to distinguish this tool from sibling metrics-related tools like 'dokploy_user_getServerMetrics' or 'dokploy_application_readAppMonitoring'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparison to sibling tools that might retrieve similar metrics. The agent would have no basis for choosing this tool over other monitoring or metrics tools in the extensive sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_removeC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true (implying data deletion) and readOnlyHint=false (a write operation), which the description's 'remove' action aligns with. However, the description adds no behavioral context beyond what annotations provide—it doesn't specify what 'remove' entails (e.g., permanent deletion, revoking access, side effects), authentication requirements, or rate limits. With annotations covering basic safety, it earns a baseline score but lacks enrichment.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is under-specified rather than concise—it includes redundant information like '[user] user.remove (POST)' and a bare parameter list without explanatory context. It's front-loaded with the tool name but wastes space on formatting instead of providing value. A single sentence like 'Removes a user by their ID' would be more effective.

  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 destructive nature (annotations show destructiveHint=true), no output schema, and 0% schema coverage, the description is incomplete. It doesn't address critical aspects like what happens post-removal (e.g., confirmation message, error handling), the impact on associated resources, or user feedback. For a destructive operation, this leaves significant gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the parameter 'userId' is undocumented in the schema. The description only lists 'userId' as a required parameter without adding any meaning—it doesn't explain what a userId is, its format (e.g., numeric ID, email), or where to find it. This fails to compensate for the schema's lack of documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a user, which is a specific verb+resource combination ('remove' + 'user'). However, it doesn't distinguish this from sibling tools like 'dokploy_user_deleteApiKey' or 'dokploy_user_update', which also operate on users but perform different actions. The purpose is clear but lacks sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user must exist), exclusions (e.g., cannot remove yourself), or related tools (e.g., 'dokploy_user_update' for modifying users instead). This leaves the agent with no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_sendInvitationC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these annotations, but it also adds no behavioral context beyond what's already in the structured data. No information about authentication requirements, rate limits, side effects, or what 'sending' actually entails is provided.

  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 brief but inefficiently structured. It wastes space repeating the tool name and HTTP method without adding value. While concise, it fails to front-load essential information about the tool's purpose, making it less helpful than it could be for the same word count.

  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?

  For a mutation tool (non-readOnly) with 2 required parameters, 0% schema description coverage, and no output schema, the description is severely inadequate. It doesn't explain what the tool does, what the parameters mean, what happens when invoked, or what to expect in return. The annotations provide basic safety hints but don't compensate for the missing operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for the two required parameters. The description simply lists parameter names without explaining what 'invitationId' and 'notificationId' represent, where to get them, or how they relate to the invitation sending process. This leaves critical parameter meaning undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('user.sendInvitation') without explaining what the tool actually does. It doesn't specify what resource is being acted upon (e.g., sending an invitation to join something) or what the expected outcome is. This is essentially a tautology that provides no additional clarity 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like 'dokploy_organization_inviteMember' and 'dokploy_organization_allInvitations' that appear related to invitations, but the description doesn't differentiate this tool from those or provide any context about appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_volumeBackups_createC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. However, the description adds minimal behavioral context beyond the parameter list—it doesn't explain that this creates a scheduled backup job, what happens when it runs (e.g., volume snapshots), or any side effects like resource usage. With annotations covering basic traits, the description adds some value but lacks depth for a creation tool.

  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 structured as a parameter list, which is somewhat organized but not front-loaded with purpose. It wastes space by repeating obvious information (e.g., 'POST') and includes redundant formatting. However, it avoids excessive verbosity, making it moderately concise but inefficient in conveying key information.

  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 (19 parameters, 0% schema coverage, no output schema) and annotations that only cover basic hints, the description is insufficient. It doesn't explain what the tool creates (a backup schedule), how it behaves, or what to expect upon success/failure. For a creation tool with many parameters, this leaves significant gaps in understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 by explaining parameters. It lists all 19 parameters with types and required status, but provides no semantic meaning—e.g., what 'prefix' is for, how 'cronExpression' formats work, or what 'destinationId' refers to. This adds little beyond the schema, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('volumeBackups.create') and lists parameters without explaining what the tool actually does. It doesn't specify that this creates a scheduled backup configuration for a volume, nor does it differentiate from sibling tools like 'dokploy_volumeBackups_update' or 'dokploy_backup_create'. The purpose is implied but not clearly stated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 doesn't mention prerequisites (e.g., needing an existing volume or destination), nor does it reference sibling tools like 'dokploy_volumeBackups_update' for modifications or 'dokploy_backup_manualBackup*' for one-time backups. Usage context is completely absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_volumeBackups_listC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear safety hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the agent knows this is a safe, repeatable read operation. The description adds no behavioral context beyond what annotations already declare, such as pagination, rate limits, or authentication requirements. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  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 brief and front-loaded with the tool name, but it wastes space on parameter formatting that duplicates the schema. The two sentences are somewhat redundant and could be more efficiently structured to convey purpose rather than restating schema details.

  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 (2 required parameters with 0% schema coverage), no output schema, and rich annotations, the description is inadequate. It fails to explain what the tool returns, how parameters interact, or the operational context (e.g., listing backups for a specific resource). Annotations cover safety, but the description doesn't add necessary context for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters ('id' and 'volumeBackupType') with types and enum values, but doesn't explain their meaning (e.g., what 'id' refers to, what the enum values represent in context). It adds minimal semantics beyond the bare schema, insufficient to compensate for the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('volumeBackups.list') and lists parameters without explaining what the tool actually does. It doesn't specify that this tool retrieves or lists volume backups, nor does it distinguish it from sibling tools like 'dokploy_volumeBackups_one' or 'dokploy_backup_listBackupFiles'. This is essentially a tautology with parameter documentation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'dokploy_volumeBackups_one' (for getting a single backup) or 'dokploy_backup_listBackupFiles' (for listing backup files), nor does it specify prerequisites, context, or exclusions for usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_whitelabeling_updateC
  2.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, idempotent, open-world operation. The description doesn't contradict these but adds minimal behavioral context—it only notes it's a POST request. It doesn't explain what 'update' entails (e.g., partial vs. full updates, effects on existing configurations, or response behavior), leaving gaps despite annotations covering basic safety.

  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 brief but under-specified—it's a single line with a parameter list, lacking explanatory content. While not verbose, it doesn't efficiently convey necessary information; the structure includes redundant details like '[whitelabeling]' and the HTTP method without adding value. It's concise but ineffective due to missing context.

  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 (updating a multi-field configuration object), lack of output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what whitelabeling is, what fields can be updated, how the update behaves, or what to expect in return. Annotations provide some safety context, but the description leaves critical gaps for a mutation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists 'whitelabelingConfig' as a required object but doesn't explain its purpose, structure, or the meaning of its nested fields (e.g., appName, logoUrl). It fails to compensate for the lack of schema documentation, offering no semantic details beyond what's evident from the parameter name.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('whitelabeling.update') and adds the HTTP method (POST), which is tautological. It doesn't explain what 'whitelabeling' means in this context or what specific aspects are being updated. While it mentions the required parameter, it doesn't articulate the tool's function 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The sibling tools include 'dokploy_whitelabeling_get', 'dokploy_whitelabeling_getPublic', and 'dokploy_whitelabeling_reset', but the description doesn't differentiate this update tool from those read or reset operations. There's no mention of prerequisites, context, or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_listBackupFilesC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation. The description adds no behavioral context beyond these annotations, such as rate limits, authentication needs, or what 'listBackupFiles' entails (e.g., pagination, format). Since annotations cover the safety profile adequately, the description meets the lower bar but adds minimal value, warranting a baseline score.

  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 and structured with a clear header and parameter list, avoiding unnecessary verbosity. However, it could be more front-loaded by starting with a purpose statement rather than the tool signature. Despite this minor structural issue, it efficiently conveys the available information without waste.

  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 (3 parameters, 0% schema coverage, no output schema) and annotations that only cover safety, the description is incomplete. It lacks details on what the tool returns, how parameters interact, or any error conditions. For a list operation with undocumented parameters, this gap hinders the agent's ability to use the tool effectively, making the description insufficient for the context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description lists parameters (destinationId, search, serverId) with types and required status, but provides no semantic meaning—e.g., what 'destinationId' refers to, how 'search' is used, or the role of 'serverId'. This partial information fails to compensate for the lack of schema descriptions, leaving key details unclear for effective tool invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name with minimal elaboration ('[backup] backup.listBackupFiles (GET)'), which is essentially tautological. It mentions 'listBackupFiles' but doesn't specify what constitutes a backup file or the scope of listing, making the purpose vague. While it implies listing files related to backups, it lacks specificity about the resource or context, failing to clearly distinguish from sibling backup tools like 'dokploy_backup_one' or 'dokploy_backup_remove'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 any context, prerequisites, or exclusions, and it fails to reference sibling tools like 'dokploy_backup_one' for retrieving a single backup or 'dokploy_backup_remove' for deletion. This absence of usage instructions leaves the agent without direction on appropriate tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_certificates_oneC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating this is a safe, non-destructive, repeatable read operation. The description adds minimal value by specifying 'GET', which aligns with the annotations but does not disclose additional behavioral traits such as error handling, rate limits, or authentication requirements. Since annotations cover the core safety profile, the description meets a baseline but lacks enriching context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is under-specified rather than concise; it consists of a tautological line and a parameter listing that repeats the schema. It lacks front-loaded clarity and wastes space on redundant information. While brief, it fails to convey essential details efficiently, making it ineffective rather than succinct.

  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 simplicity (one parameter, no output schema) and rich annotations, the description is incomplete. It does not explain the return value, error conditions, or how this tool fits into the broader certificate management context. While annotations cover safety, the description fails to provide enough context for the agent to understand the tool's role and expected outcomes fully.

  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 description lists 'certificateId (string, required)' under 'Parameters:', which mirrors the input schema exactly. With schema description coverage at 0%, the description does not add meaning beyond the schema (e.g., explaining what a certificateId is, its format, or where to find it). However, since there is only one parameter and the schema defines it clearly, the baseline score of 3 is appropriate as the description does not compensate for the low coverage but the parameter is straightforward.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[certificates] certificates.one (GET)' is tautological, essentially restating the tool name and title with minimal additional context. It mentions 'certificates' and 'GET' but lacks a specific verb-action-resource combination that clearly states what the tool does (e.g., 'Retrieve details for a specific certificate'). It does not distinguish this tool from sibling certificate tools like 'dokploy_certificates_all' or 'dokploy_certificates_create', leaving the purpose vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, nor does it refer to sibling tools for comparison. Without any usage instructions, the agent lacks direction on appropriate invocation scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_cancelDeploymentC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true and destructiveHint=false, indicating this is a safe read operation. The description doesn't contradict these annotations, but it also doesn't add meaningful behavioral context beyond what's already implied by 'cancelDeployment'. It doesn't explain what happens to the deployment, whether it's reversible, or what the response looks like. With annotations covering safety, this gets a baseline score.

  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 extremely concise - just two lines showing the HTTP method and parameter. While this is efficient, it's arguably too terse given the lack of explanatory content. However, it's well-structured and front-loaded with the essential technical details.

  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?

  For a tool that performs an action like 'cancelDeployment', the description is insufficient. There's no output schema, no explanation of what happens when deployment is cancelled, no error conditions mentioned, and no context about what 'compose' represents in this system. The annotations help with safety understanding, but the description leaves too many questions unanswered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for the single parameter. The description only lists the parameter name without explaining what 'composeId' represents, how to obtain it, or what format it should be in. This adds minimal value beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and HTTP method without explaining what 'cancelDeployment' means in the context of 'compose'. It mentions the required parameter but doesn't clarify what resource is being acted upon or what the cancellation entails. This is a tautology rather than a clear purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like 'dokploy_application_cancelDeployment' and 'dokploy_compose_stop' that might serve similar purposes, but the description doesn't differentiate this tool from them or explain when cancellation is appropriate versus other actions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_oneC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal value by specifying 'GET', which aligns with read-only behavior, but doesn't disclose additional traits like rate limits, authentication needs, or what 'compose.one' entails (e.g., retrieving a single compose resource). No contradiction with annotations exists.

  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 brief and structured with a header and parameter list, avoiding redundancy. However, it's overly terse, sacrificing clarity for brevity. Every sentence (or line) serves a purpose, but the content is minimal, making it efficient yet under-informative.

  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?

  For a tool with one parameter, no output schema, and rich annotations, the description is incomplete. It doesn't explain what 'compose.one' returns or its role in the system, leaving gaps in understanding despite annotations covering safety. Given the complexity implied by sibling tools, more context is needed for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, with one required parameter 'composeId'. The description lists the parameter but adds no semantic meaning beyond what the schema provides (e.g., what a composeId is, format examples, or where to find it). Given low coverage, the description fails to compensate, leaving the parameter's purpose unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[compose] compose.one (GET)' restates the tool name and HTTP method but provides minimal functional clarity. It mentions 'compose' which suggests a Docker Compose context, but doesn't specify what action is performed (e.g., retrieve, view, get details). Compared to sibling tools like 'dokploy_compose_create' or 'dokploy_compose_delete', the purpose is vague and lacks a clear verb+resource distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or differentiate from other compose-related tools (e.g., 'dokploy_compose_search', 'dokploy_compose_getTags'). The agent must infer usage from the name alone, which is insufficient for effective tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_destination_testConnectionC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. However, the description adds minimal behavioral context beyond what annotations provide—it implies a test action via 'POST' but doesn't disclose what 'testConnection' entails (e.g., whether it validates credentials, pings a service, returns success/failure, or has side effects like logging). For a tool with no output schema, more detail on expected behavior would be helpful, but it doesn't mislead.

  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 and front-loaded with the tool name and method, followed by a structured parameter list. However, the parameter list is redundant with the schema and doesn't add value, slightly reducing efficiency. Overall, it's well-structured but could be more purposeful in its brevity.

  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 8 parameters with 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is incomplete. It doesn't explain what the tool tests, what the parameters mean, what the expected outcome is, or how it differs from sibling test tools. For a connection-testing tool with sensitive parameters like 'secretAccessKey', more context is needed to ensure correct and secure usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists parameter names and types but adds no semantic meaning beyond what the input schema already provides. With 0% schema description coverage, the schema only defines data types and constraints, leaving parameters like 'provider' (type 'any') and 'secretAccessKey' completely unexplained. The description fails to compensate by explaining what these parameters represent (e.g., provider could be AWS S3, endpoint is the service URL), making it inadequate for guiding usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name 'destination.testConnection' without explaining what it actually does. It doesn't specify what resource is being tested (e.g., storage destination configuration) or what 'testConnection' means in this context (e.g., validating credentials, connectivity, or permissions). While it mentions 'POST' which indicates an action, the purpose remains vague and indistinguishable from sibling tools like dokploy_bitbucket_testConnection or dokploy_gitea_testConnection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a destination configuration first), context (e.g., during setup or troubleshooting), or exclusions (e.g., not for production use). With many sibling tools including other testConnection variants, the lack of differentiation makes it impossible for an agent to determine when this specific tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_environment_duplicateC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=false (non-idempotent), and openWorldHint=true (open-world). The description doesn't contradict these but adds minimal behavioral context - it mentions it's a POST operation, implying creation. However, it lacks details on what gets duplicated (e.g., settings, resources), whether it requires specific permissions, or what the expected outcome is. With annotations covering safety, a 3 reflects some value from the HTTP method hint but insufficient behavioral depth.

  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 with no wasted words, structured as a brief header followed by a parameter list. However, it's overly terse - the header is cryptic ('[environment] environment.duplicate'), and the parameter list lacks explanatory value. While efficient, it sacrifices clarity for brevity.

  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 this is a mutation tool (readOnlyHint=false) with 3 parameters, 0% schema coverage, no output schema, and no behavioral details in the description, it's incomplete. The agent lacks understanding of what the tool does beyond 'duplicate', what parameters mean, what the result looks like, or how it differs from other environment tools. Annotations help but don't compensate for the sparse description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters (environmentId, name, description) but only adds basic type/requirement info already in the schema. It doesn't explain what environmentId refers to (e.g., ID of source environment), what name/description apply to (the duplicate), or any constraints (e.g., name uniqueness). For 3 parameters with zero schema coverage, this minimal info is inadequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[environment] environment.duplicate (POST)' which is tautological - it essentially restates the tool name with minimal clarification. It doesn't specify what 'duplicate' means operationally (creates a copy with new name/description? preserves settings?), nor does it distinguish from sibling environment tools like dokploy_environment_create or dokploy_environment_update. The purpose is vague beyond the basic verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 doesn't mention prerequisites (e.g., needing an existing environment), use cases (e.g., cloning configurations), or exclusions. With many sibling tools for environment management, this lack of differentiation leaves the agent guessing about appropriate context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_github_updateC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key behavioral hints: readOnlyHint=false (mutation), destructiveHint=false (safe), idempotentHint=true (repeatable), openWorldHint=true (broad scope). The description adds no behavioral context beyond these annotations—no mention of side effects, permissions, or response format. Since annotations cover core traits adequately, the description's lack of additional context results in a baseline score.

  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 brief and structured with a clear header and parameter list. However, the first line '[github] github.update (POST)' is redundant with the tool name and title, and the parameter listing adds little value without explanations. It's concise but under-informative rather than efficiently packed with insights.

  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 4 parameters with 0% schema coverage, no output schema, and annotations that don't explain parameter purposes or mutation details, the description is incomplete. It doesn't clarify what the tool updates (e.g., GitHub provider settings), what the parameters mean, or what the outcome is. For a mutation tool with undocumented inputs, this is insufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides only names and types without meanings. The description lists parameter names but adds no semantic explanation (e.g., what 'githubId' refers to, what 'gitProviderId' is, or how 'githubAppName' is used). This fails to compensate for the schema's lack of descriptions, leaving parameters ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('github.update') without clarifying what specific GitHub resource is being updated or what fields are modified. It lists parameters but doesn't explain the action's purpose beyond the tautological 'update'. Compared to siblings like 'dokploy_github_testConnection' or 'dokploy_github_getGithubRepositories', it lacks differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., existing GitHub provider), when-not-to-use scenarios, or related tools like 'dokploy_github_create' or 'dokploy_github_testConnection'. This leaves the agent guessing about appropriate contexts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_saveEnvironmentC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is not read-only, not destructive, not idempotent, and open-world. The description adds minimal behavioral context by specifying it's a POST request, implying a mutation, but does not elaborate on effects (e.g., whether it overwrites or merges environment variables, or if it triggers redeployment). With annotations covering basic safety, the description adds some value 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and structured with a clear header and parameter list. However, it includes redundant information (repeating the tool name) and lacks essential explanatory content. While concise, it under-specifies rather than being efficiently informative.

  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 has no output schema, annotations provide basic hints, and schema coverage is 0%, the description is incomplete. It does not explain the purpose, parameter usage, or expected outcomes (e.g., success response or error handling). For a mutation tool with undocumented parameters, this is inadequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameters ('mariadbId', 'env') but gives no semantic meaning (e.g., 'mariadbId' identifies the MariaDB instance, 'env' contains environment variables as key-value pairs). It fails to compensate for the schema's lack of descriptions, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('mariadb.saveEnvironment') without adding meaningful clarification. It mentions 'POST' and lists parameters, but fails to specify what 'saveEnvironment' actually does (e.g., saves environment variables for a MariaDB instance). This is a tautology that provides no additional insight beyond the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or sibling tools (e.g., other 'saveEnvironment' tools for different databases like mongo or mysql). Without this, an agent cannot determine appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mounts_removeC
  2.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a removal action. However, the description adds minimal behavioral context beyond annotations—it doesn't specify if removal is permanent, requires specific permissions, or affects running services. Since annotations cover key safety aspects (destructive, non-idempotent), the description's lack of extra detail is acceptable but not comprehensive, warranting a score above baseline but not perfect.

  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 brief but poorly structured—it mixes tool path ('[mounts] mounts.remove'), HTTP method ('POST'), and parameter listing in a single line without clear separation. While it avoids unnecessary verbosity, the formatting is cluttered and doesn't front-load critical information (e.g., purpose first). It could be more readable with better organization.

  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?

  For a destructive tool with no output schema and 0% parameter coverage, the description is inadequate. It doesn't explain the outcome of removal (e.g., success response, error cases), dependencies, or system impact. Given the complexity implied by annotations (destructive, non-idempotent), more context is needed to guide safe usage, making this description incomplete for effective tool invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the input schema provides no descriptions for parameters. The description only lists 'mountId' as a required string without explaining what a mount ID is, how to obtain it, or its format (e.g., UUID). This fails to compensate for the schema's lack of documentation, leaving the parameter's meaning unclear to the agent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('mounts.remove') without clarifying what 'mounts' are or what 'remove' entails beyond deletion. It mentions 'POST' as the HTTP method, which is redundant with the tool's action. While it implies a deletion operation, it lacks specificity about the resource being removed (e.g., storage mounts in a deployment environment) and doesn't distinguish it from sibling tools like 'dokploy_mounts_create' or 'dokploy_mounts_update'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing mount ID), conditions for safe removal, or what happens after deletion (e.g., impact on associated services). With many sibling tools for mounts (create, update, list), the absence of usage context leaves the agent guessing about appropriate scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mysql_saveExternalPortC
  2.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond the name. It doesn't explain what 'saving an external port' entails (e.g., whether it updates configuration, requires restart, affects connectivity, or has side effects). With annotations covering basic hints, the description fails to provide meaningful additional behavioral insight.

  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 brief but inefficiently structured. It includes redundant information like '[mysql]' and '(POST)' which might be inferred from context, and the parameter listing adds little value without explanations. While not verbose, it lacks front-loaded purpose and wastes space on unhelpful details.

  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 (mutation operation with 2 parameters), 0% schema coverage, no output schema, and annotations that only provide basic hints, the description is inadequate. It doesn't explain what the tool does, how to use it, what the parameters mean, or what to expect as a result, leaving significant gaps for the agent to understand and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (mysqlId, externalPort) but provides no semantic meaning—what a mysqlId is, what externalPort represents, acceptable values, or that externalPort can be null. The description merely repeats parameter names without adding context, failing to address the schema's documentation gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name and HTTP method but lacks a clear purpose statement. It mentions 'mysql.saveExternalPort' which suggests saving an external port for a MySQL instance, but this is inferred from the name rather than explicitly stated. No specific verb-resource combination is provided, and it doesn't distinguish from sibling tools like dokploy_mariadb_saveExternalPort or dokploy_postgres_saveExternalPort.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this operation is appropriate, or what other tools might be related (e.g., other database port configuration tools in the sibling list). This leaves the agent with no contextual usage information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_port_updateC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (can create new resources). The description adds no behavioral context beyond what annotations already declare. It doesn't explain what 'update' entails (e.g., whether it replaces or merges settings, error conditions, or side effects). However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  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 and structured as a parameter list, which is efficient. However, it lacks a proper introductory sentence explaining the tool's purpose, making it feel incomplete rather than optimally concise. Every line serves a purpose, but the overall structure is minimalistic.

  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 5 parameters with 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is insufficient. It doesn't explain what the tool does, how to use it, what the parameters mean, or what to expect upon success/failure. For a mutation tool with multiple parameters, this leaves significant gaps for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description lists parameter names and types but provides no semantic meaning (e.g., what portId refers to, the difference between publishedPort and targetPort, what publishMode values imply). This minimal listing doesn't adequately compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description merely restates the tool name as '[port] port.update (POST)' without explaining what 'update' means in this context. It doesn't specify what resource is being updated (a port configuration for a service/application) or what the update entails. While it lists parameters, this doesn't constitute a clear purpose statement beyond the tautological name repetition.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 sibling tools list includes dokploy_port_create, dokploy_port_delete, and dokploy_port_one, but the description provides no context about when to choose update over create or delete, or what prerequisites might exist (e.g., needing an existing port).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_oneC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already inform the agent this is a safe, non-destructive, repeatable read operation. The description adds minimal value by implying it's a GET request, but doesn't disclose any additional behavioral traits like rate limits, authentication needs, or what specifically happens when invoked. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is under-specified rather than concise. It includes unnecessary formatting like brackets and parentheses ('[postgres] postgres.one (GET)') without adding clarity. The parameter listing is minimal but lacks explanation. The structure is not front-loaded with purpose, making it inefficient for an agent to parse.

  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 has no output schema and annotations cover basic safety, the description is incomplete. It fails to explain what the tool returns (e.g., details of a PostgreSQL instance), any prerequisites, or error conditions. For a tool that likely retrieves specific PostgreSQL data, this leaves significant gaps in understanding its full context and usage.

  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 0%, meaning the schema provides no descriptions for the single parameter 'postgresId'. The description lists the parameter but adds no semantic meaning beyond its name (e.g., what a postgresId is, where to find it, format expectations). Since there's only one parameter and schema coverage is low, the description partially compensates by at least naming it, but doesn't provide sufficient context for effective use.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and HTTP method ('postgres.one (GET)') without specifying what the tool actually does. It mentions 'postgres' but doesn't indicate whether this retrieves, creates, updates, or performs another action on a PostgreSQL resource. The description is tautological and lacks a clear verb+resource statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include multiple 'postgres_' tools (create, delete, deploy, move, rebuild, etc.), there is no indication of when this specific 'one' tool should be selected over others like 'dokploy_postgres_search' or 'dokploy_postgres_update'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_project_oneC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a read-only, non-destructive, idempotent, and open-world operation, which the description does not contradict. However, the description adds minimal behavioral context beyond these annotations—it only specifies a GET method. It lacks details on error handling, rate limits, authentication needs, or what specific project data is returned, leaving gaps in understanding the tool's behavior despite the annotations covering basic safety.

  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 and front-loaded, stating the operation and parameters in a clear, two-line format without unnecessary words. However, its brevity borders on under-specification, as it omits critical details like the tool's purpose and usage context, which reduces its overall effectiveness despite the efficient structure.

  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 simplicity (one parameter) and rich annotations, the description is incomplete. It lacks output details (no output schema provided), fails to explain the return value or potential errors, and does not clarify the tool's role within the broader context of project management tools. This leaves significant gaps for an AI agent to understand how to use the tool effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'projectId' as a required string parameter, but with 0% schema description coverage, it does not add meaningful semantics beyond what the input schema already specifies (type, minLength). It fails to explain what a 'projectId' is (e.g., format, source, or examples), how to obtain it, or its role in the operation, leaving the parameter poorly understood despite the schema's structural details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[project] project.one (GET)' is tautological, essentially restating the tool name 'dokploy_project_one' with minimal additional context. It indicates a GET operation on a project resource but lacks specificity about what 'project.one' entails (e.g., retrieving details, status, or metadata). It does not distinguish this tool from sibling tools like 'dokploy_project_all' or 'dokploy_project_search', leaving the purpose vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., after creating a project), or comparisons with sibling tools such as 'dokploy_project_all' for listing projects or 'dokploy_project_search' for filtered searches. This absence of usage instructions could lead to incorrect tool selection by an AI agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redirects_createC
  2.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide basic hints (not read-only, not destructive, not idempotent, open world), but the description adds almost no behavioral context. It doesn't explain what 'creates' means operationally - whether this creates persistent configuration, requires specific permissions, has side effects, or what happens on duplicate entries. For a creation tool with no idempotence hint, the description should clarify creation behavior but doesn't.

  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 concise but poorly structured. It starts with redundant information '[redirects] redirects.create (POST)' that repeats the tool name, then provides a parameter list. While brief, it wastes the opening line on tautology rather than explaining purpose. The parameter list format is clear but could be better integrated with explanatory 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?

  For a creation tool with 4 parameters, 0% schema coverage, no output schema, and sibling tools that suggest a redirect management system, this description is inadequate. It doesn't explain what redirects are in this system, how they're used, what the creation process entails, or what the expected outcome is. The parameter list helps but doesn't compensate for missing operational 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?

  With 0% schema description coverage, the description carries the full burden of parameter documentation. It lists all 4 parameters with their types and required status, which is valuable. However, it doesn't explain what each parameter means (e.g., what 'regex' matches against, what 'replacement' format is expected, what 'permanent' means for HTTP status codes, what 'applicationId' refers to). The parameter listing is helpful but lacks semantic context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is tautological - it essentially restates the tool name 'redirects.create' and adds HTTP method 'POST'. It doesn't explain what the tool actually does (creates URL redirects/routing rules). While it mentions 'redirects', it doesn't specify what kind of redirects (HTTP, URL routing, etc.) or in what context (web server, application, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. There are sibling tools like 'dokploy_redirects_delete', 'dokploy_redirects_one', and 'dokploy_redirects_update', but the description provides no differentiation or indication of when to choose create vs update vs delete. No prerequisites, alternatives, or context are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_getDefaultCommandC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive behavioral hints (read-only, non-destructive, idempotent, open-world). The description adds minimal value by specifying the HTTP method (GET), but doesn't provide any additional context about what 'default command' means, potential side effects, authentication requirements, or rate limits. The description doesn't contradict annotations, but adds little beyond what annotations already convey.

  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 brief and structured with clear parameter listing. However, the first line '[server] server.getDefaultCommand (GET)' is redundant with the tool name and title, making it slightly wasteful. The overall structure is clean but could be more efficient by eliminating the redundant prefix.

  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 lack of output schema and 0% parameter documentation coverage, the description is insufficient. It doesn't explain what 'default command' means in this context, what format the response will have, or how this tool relates to the broader server management functionality. For a tool with rich annotations but no output schema, the description should provide more context about the expected return value.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage for the single parameter (serverId), the description provides no additional semantic meaning beyond what's in the schema. It merely lists the parameter name without explaining what a serverId is, how to obtain it, or what format it should have. The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and HTTP method without explaining what 'getDefaultCommand' means or what resource it operates on. It's a tautology that doesn't clarify the actual purpose beyond what's already in the name. The description should specify what default command is being retrieved and for what type of server.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (including other 'getDefaultCommand' tools for different resources like compose), there's no indication of when this specific server-related tool is appropriate versus other server tools or general retrieval tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_securityC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), which already inform the agent this is a safe, non-destructive, repeatable operation that may return partial data. The description adds minimal value beyond annotations - it confirms it's a GET operation but doesn't disclose additional behavioral traits like authentication requirements, rate limits, error conditions, or what 'security' data format to expect. No contradiction with annotations exists.

  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 extremely concise - just two lines showing the endpoint and parameter. While this avoids verbosity, it's arguably too brief given the tool's complexity. The structure is clear but under-specified; every word earns its place, but more content would be beneficial for understanding. It's front-loaded with the endpoint but lacks elaboration.

  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 potential complexity (security operations often involve sensitive data), the description is inadequate. Annotations cover safety aspects, but there's no output schema, and the description doesn't explain what security information is returned (e.g., firewall settings, access logs, compliance status). With 0% schema coverage and no output details, the agent lacks sufficient context to use this tool effectively beyond knowing it's a safe GET request.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the parameter 'serverId' has no documentation in the schema. The description only lists 'serverId (string, required)' without explaining what a serverId is, where to find it, its format, or valid values. This fails to compensate for the complete lack of schema documentation, leaving the parameter's meaning ambiguous despite being the only required input.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[server] server.security (GET)' is tautological - it essentially restates the tool name 'dokploy_server_security' with minimal clarification. It indicates a GET operation on server security, but doesn't specify what 'security' entails (e.g., security settings, status, configuration). Compared to siblings like 'dokploy_server_getServerMetrics' or 'dokploy_server_validate', the purpose remains vague about what security information is retrieved.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'dokploy_server_all', 'dokploy_server_one', 'dokploy_security_one'), there's no indication of whether this is for retrieving general server information, specific security configurations, or how it differs from other security-related tools. No prerequisites, exclusions, or context for usage are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_validateC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already tell the agent this is a safe, repeatable read operation. The description adds minimal behavioral context by specifying it's a GET request, but doesn't explain what validation entails, what happens on failure/success, or any side effects. With good annotation coverage, the bar is lower, but the description adds only basic HTTP method information.

  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 extremely concise with only two lines. It's front-loaded with the tool signature and lists the parameter. However, the conciseness comes at the cost of being under-specified rather than efficiently informative. No sentences are wasted, but more content would be beneficial.

  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 this is a validation tool with no output schema, the description should explain what the tool returns (validation results, status, errors). The annotations cover safety aspects well, but the description fails to explain what 'validate' means operationally, what constitutes success/failure, or what the agent can expect as output. For a validation operation, this leaves significant gaps in understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for the single parameter (serverId). The description only lists 'serverId (string, required)' without explaining what a serverId is, where to find it, its format, or what validation is performed on it. For a tool with zero schema coverage, this minimal parameter listing is insufficient compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[server] server.validate (GET)' which is essentially a tautology of the tool name and title. It doesn't explain what 'validate' means in this context - whether it validates server configuration, connectivity, permissions, or something else. While it mentions the server resource, the verb 'validate' remains vague without clarifying what aspect is being validated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools (including dokploy_server_setup, dokploy_server_update, dokploy_server_one, dokploy_server_security, etc.), there's no indication of when validation is appropriate versus other server operations. No prerequisites, timing, or context for usage is mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanUnusedVolumesC
  2.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear behavioral hints: readOnlyHint=false (mutation), destructiveHint=true (destructive), idempotentHint=false (non-idempotent), and openWorldHint=true (open-world). The description does not contradict these annotations. While it adds no extra behavioral context beyond what annotations already cover, the annotations are comprehensive, so the description's minimal addition does not harm transparency. No contradiction is present.

  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 concise with two lines, but it is not well-structured or front-loaded. The first line is cryptic ('[settings] settings.cleanUnusedVolumes (POST)'), and the second line merely lists a parameter without integration. While brief, it lacks clarity and could be more effectively organized to convey purpose upfront.

  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 (destructive mutation with one parameter), the description is incomplete. Annotations cover safety aspects, but the description lacks purpose clarity, usage guidelines, and parameter semantics. With no output schema and low schema coverage, the description does not compensate for these gaps, making it inadequate for informed tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'serverId (string, optional)' but provides no semantic explanation. With 0% schema description coverage and one parameter, the description fails to add meaningful context beyond the schema's type information. It does not explain what 'serverId' refers to, its format, or implications of being optional, leaving the parameter poorly documented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.cleanUnusedVolumes (POST)' restates the tool name and title with minimal elaboration. It indicates a POST action on a settings-related endpoint but lacks a specific verb and resource definition. While it hints at cleaning unused volumes, the purpose is vague and does not clearly distinguish this tool from sibling settings tools like 'cleanAll', 'cleanUnusedImages', or 'cleanStoppedContainers'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions. Given the many sibling tools with similar 'clean' operations, the absence of usage guidelines is a significant gap, leaving the agent without direction on appropriate invocation scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_setupGPUC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, idempotent, open-world operation. The description adds minimal behavioral context beyond annotations—it implies a setup/configuration action via 'POST' but doesn't detail effects (e.g., whether it installs drivers, allocates resources, or requires specific permissions). With annotations covering safety and idempotency, the description adds some value but lacks depth on implementation specifics.

  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 brief and front-loaded with the tool path and method, but it wastes space on redundant formatting (brackets, parentheses). It efficiently conveys basic structure in two lines, though it could be more polished by integrating the parameter note into a cohesive sentence.

  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 likely complexity (GPU setup), lack of output schema, and 0% schema coverage, the description is insufficient. It doesn't explain what 'setupGPU' entails, expected outcomes, error conditions, or dependencies. With annotations providing some safety context, it still leaves critical gaps for effective agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'serverId (string, optional)' but provides no semantic meaning (e.g., which server to target, default behavior if omitted, format requirements). This adds minimal value beyond the schema's type information, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name/title ('settings.setupGPU') without explaining what it does. It mentions 'POST' which indicates an HTTP method but doesn't specify the action (e.g., configure, enable, initialize GPU settings). This is a tautology that provides minimal clarity beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., after server setup), or related tools like 'dokploy_settings_checkGPUStatus' or 'dokploy_server_setup' from the sibling list. This leaves the agent with no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_checkUserOrganizationsC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive safety information (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description's burden is reduced. The description adds that this is a GET operation, which aligns with the read-only annotation. However, it doesn't provide any additional behavioral context about what 'check' entails, error conditions, or response format.

  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 extremely concise - just two lines showing the method and parameter. While it's front-loaded with the essential information, it's arguably too brief given the complete lack of explanatory content about the tool's purpose and usage.

  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 has no output schema and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool returns (organizations list? membership status? validation result?), nor does it provide any context about the Dokploy system's organization model. The annotations help, but the description leaves too many gaps for effective tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'userId (string, required)' without explaining what a valid userId looks like, where to obtain it, or what happens if an invalid userId is provided. The description adds minimal value beyond what's already in the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('user.checkUserOrganizations') and method ('GET') without explaining what the tool actually does. It doesn't specify what 'checkUserOrganizations' means - whether it retrieves, verifies, or lists organizations for a user. This is a tautology that provides minimal value 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are many user-related tools in the sibling list (dokploy_user_get, dokploy_user_one, dokploy_user_getPermissions, etc.), but the description doesn't differentiate this tool from them or indicate appropriate use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_oneC
  2.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation. The description adds minimal value by specifying 'GET', which aligns with read-only behavior, but doesn't disclose additional traits like authentication needs, rate limits, or error conditions. With annotations covering core safety, a baseline score is appropriate.

  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 brief and front-loaded with the tool name and method, but it's under-specified rather than concise. While it avoids unnecessary words, it sacrifices clarity for brevity. A single line with the parameter listed is structured but incomplete.

  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 simplicity (1 parameter, no output schema) and rich annotations, the description is incomplete. It lacks purpose clarity, usage guidelines, and parameter semantics, making it insufficient for an agent to use effectively. Annotations help but don't fully compensate for the missing contextual details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only defines 'userId' as a required string without explaining its meaning. The description lists 'userId' but provides no semantic context (e.g., what format it expects, where to find it, or its role in fetching a user). This fails to compensate for the lack of schema descriptions, leaving the parameter poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.one (GET)' restates the tool name and HTTP method but lacks a clear verb and resource specification. It doesn't explain what 'user.one' does (e.g., retrieve a specific user by ID) or distinguish it from sibling tools like 'dokploy_user_get' or 'dokploy_user_all'. This is closer to a tautology than a meaningful purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'dokploy_user_get' and 'dokploy_user_all', the description offers no context on differences (e.g., this tool might fetch a single user by ID while others list users). This leaves the agent without direction on tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_ai_getAllC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds no behavioral context beyond this, such as rate limits, authentication needs, or what 'getAll' entails (e.g., pagination, sorting). Since annotations are comprehensive, the bar is lower, but the description does not enhance understanding beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[ai] ai.getAll (GET)'), but this brevity results in under-specification rather than efficient communication. It fails to convey purpose or usage, making it ineffective despite its short length. Every sentence should earn its place, and this single fragment does not provide sufficient value.

  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 simplicity (0 parameters, comprehensive annotations), the description is incomplete. It lacks purpose clarity and usage guidelines, and there is no output schema to explain return values. While annotations cover behavioral aspects, the description does not provide enough context for an agent to understand what the tool does or when to use it, making it inadequate overall.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description does not add parameter information, which is unnecessary here. With no parameters, the baseline is 4, as the description need not compensate for any gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[ai] ai.getAll (GET)' is tautological, essentially restating the tool name and adding the HTTP method. It does not specify what resource 'ai' refers to or what 'getAll' actually retrieves. While it distinguishes from siblings by implying a bulk retrieval operation, it lacks a clear verb+resource statement like 'retrieve all AI models' or similar.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or exclusions, nor does it refer to sibling tools like 'dokploy_ai_get' or 'dokploy_ai_getModels' for comparison. This leaves the agent with no usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_cleanQueuesC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true (implying data loss or irreversible changes) and readOnlyHint=false (confirming it's a mutation). The description does not contradict these but adds minimal behavioral context beyond the annotations. It specifies the HTTP method (POST) and required parameter, but does not elaborate on what 'cleanQueues' entails (e.g., whether it deletes queue entries, stops processes). With annotations covering safety, the description adds some value but lacks detailed behavioral traits.

  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 brief and front-loaded with the tool name and method, but it includes redundant formatting (brackets, parentheses) and lacks efficient structuring. It wastes space on obvious details (e.g., 'POST') without adding informative content. While concise, it under-specifies rather than being efficiently informative.

  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 destructive nature (annotations: destructiveHint=true), no output schema, and low parameter coverage, the description is incomplete. It fails to explain the outcome (e.g., what 'cleanQueues' returns or affects), prerequisites, or error conditions. For a mutation tool with potential data loss, more context is needed to guide safe usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists 'applicationId' as a required string but does not explain its purpose (e.g., identifier for the target application), format, or constraints. This adds minimal semantics beyond the schema's type and requirement, insufficient to compensate for the low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('application.cleanQueues') and HTTP method ('POST'), which is tautological. It does not specify what 'cleanQueues' means (e.g., clearing deployment queues, removing pending tasks) or what resource it acts upon beyond the generic 'application' context. This lacks a clear verb+resource distinction, making the purpose vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. Sibling tools include 'dokploy_application_clearDeployments' and 'dokploy_compose_cleanQueues', which might serve similar purposes, but the description does not differentiate or provide any context for selection. This absence of usage instructions is misleading for an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_saveGithubProviderC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation with open-world hints, but the description adds no behavioral context. It doesn't explain what 'save' entails (e.g., creation, update, or configuration), potential side effects, or error conditions, relying solely on annotations.

  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 brief but inefficiently structured as a parameter list without explanatory text. It front-loads the tool name and method but wastes space on a basic parameter enumeration that adds little value beyond the schema.

  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?

  For a tool with 9 parameters, no output schema, and 0% schema coverage, the description is inadequate. It lacks purpose clarity, usage context, parameter explanations, and behavioral details, making it insufficient for effective agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 9 parameters, the description lists parameters but provides no semantic meaning (e.g., what 'githubId' refers to, how 'watchPaths' are used). It fails to compensate for the lack of schema documentation, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and HTTP method (POST) but doesn't explain what 'saveGithubProvider' means. It's unclear whether this creates, updates, or configures a GitHub provider for an application. While it mentions parameters, the core purpose remains vague.

  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 versus alternatives like 'saveGitProvider' or 'saveGitlabProvider' is provided. The description doesn't mention prerequisites, such as needing an existing application or GitHub connection, leaving usage context unclear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_stopC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is not read-only, not destructive, not idempotent, and open-world. The description adds minimal behavioral context by specifying it's a POST operation, implying a state change. However, it doesn't elaborate on what 'stop' means operationally (e.g., graceful shutdown, immediate termination, effect on dependencies) or any side effects. With annotations covering basic safety, the description adds little extra value.

  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 brief but inefficiently structured. It includes redundant information (the tool name in brackets) and a parameter list that merely repeats the schema. While not verbose, it wastes space on obvious details instead of adding value. A single concise sentence explaining the action would be more effective.

  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?

  For a state-change tool with no output schema and minimal annotations, the description is inadequate. It doesn't explain what happens when the tool is invoked (e.g., success/failure responses, time to stop, error conditions). Given the complexity implied by sibling tools (e.g., start, deploy, reload), more context on behavior and outcomes is needed for the agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'applicationId' as a required parameter without explaining what it represents (e.g., UUID, name, how to obtain it) or its format. For a single parameter with no schema documentation, the description fails to compensate by providing meaningful semantic context, leaving the agent guessing about valid inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('application.stop') without adding meaningful context about what 'stop' entails. It mentions the required parameter but doesn't explain what stopping an application does (e.g., halts processes, stops containers, changes state). While it includes the HTTP method (POST), this doesn't clarify the action's purpose beyond the obvious 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 is provided about when to use this tool versus alternatives like 'dokploy_application_start' or 'dokploy_application_reload'. The description doesn't mention prerequisites (e.g., the application must be running), consequences of stopping, or when it's appropriate versus other state-change tools. Sibling tools include many application management options, but no differentiation is offered.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_bitbucket_bitbucketProvidersC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide comprehensive behavioral information (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the bar is lower. The description adds minimal value by indicating this is a GET operation, which aligns with the read-only annotation. However, it doesn't provide any additional context about what 'bitbucketProviders' represents, what data is returned, or any system-specific behaviors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise, the description is under-specified rather than efficiently informative. It consists of a single bracketed phrase that doesn't form a complete sentence or provide meaningful information. The structure doesn't front-load key information about the tool's purpose or usage.

  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 rich annotations and complete schema coverage, the description is still inadequate. For a tool that presumably retrieves Bitbucket provider information, the description should explain what 'bitbucketProviders' are in this context, what data is returned, and how this differs from other provider-related tools. The absence of an output schema means the description should ideally indicate what kind of data is returned.

  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 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain any parameters since there are none. The schema fully documents the empty input structure, so no additional parameter semantics are required from the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[bitbucket] bitbucket.bitbucketProviders (GET)' is essentially a tautology that restates the tool name and adds the HTTP method. It doesn't specify what the tool actually does - whether it lists, retrieves, or manages Bitbucket providers. While it mentions 'bitbucketProviders', it doesn't explain what these are or what operation is being performed on them beyond the generic 'GET'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. There are multiple sibling tools related to Bitbucket (dokploy_bitbucket_create, dokploy_bitbucket_one, dokploy_bitbucket_update) and other provider tools (dokploy_gitea_giteaProviders, dokploy_github_githubProviders, dokploy_gitlab_gitlabProviders), but no indication of when this specific tool is appropriate versus those alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_certificates_allC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover key behavioral traits (read-only, non-destructive, idempotent, open-world), so the description's burden is lower. The description adds minimal context by implying a GET operation for certificates, but it does not disclose additional behavioral details like response format, pagination, or error handling. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of being cryptic ('[certificates] certificates.all (GET)'). It lacks a clear, front-loaded explanation of the tool's purpose, making it inefficient for quick understanding despite its brevity.

  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 simplicity (0 parameters, no output schema) and rich annotations, the description is incomplete. It fails to explain what 'certificates.all' entails (e.g., listing all certificates, their format, or scope), leaving gaps in understanding the tool's function and output.

  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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the absence of parameters, aligning with the baseline for zero parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[certificates] certificates.all (GET)' is vague and tautological. It restates the tool name with minimal context, failing to specify what the tool actually does (e.g., list all certificates, retrieve certificate details). It does not clearly distinguish from sibling tools like 'dokploy_certificates_one' or 'dokploy_certificates_create'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It lacks any mention of context, prerequisites, or comparisons to sibling tools (e.g., 'dokploy_certificates_one' for a single certificate), leaving the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_killBuildC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, indicating this is a destructive, non-idempotent write operation that may have side effects. The description adds value by specifying the HTTP method (POST), which aligns with the annotations (non-read-only, destructive). It doesn't contradict annotations but also doesn't provide additional behavioral context like rate limits, authentication needs, or what exactly gets 'killed' (e.g., build process, resources). With annotations covering core traits, the description's addition of POST method is helpful but not extensive.

  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 concise with two lines: one for the tool signature and one for parameters. However, it's under-specified rather than efficiently informative—the first line '[compose] compose.killBuild (POST)' is somewhat redundant with the tool name, and the parameter listing adds little value. While not verbose, it lacks essential details that would make it truly helpful, making it more sparse than optimally concise.

  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 (destructive operation with one parameter), annotations provide good coverage for behavioral traits, but there is no output schema. The description is incomplete: it doesn't explain the outcome of 'killBuild', error conditions, or return values. With 0% schema description coverage and no output schema, the description should do more to clarify parameter semantics and tool behavior, but it falls short, leaving significant gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description lists 'composeId (string, required)' but adds no semantic meaning—it doesn't explain what a composeId is, its format, or where to find it. For a single parameter with no schema documentation, the description fails to compensate, leaving the parameter's purpose unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'compose.killBuild (POST)' which partially indicates the action (killBuild) and resource (compose), but it's vague about what 'killBuild' specifically does—whether it terminates a build process, cancels a deployment, or something else. It doesn't distinguish from sibling tools like 'dokploy_application_killBuild' or 'dokploy_compose_cancelDeployment', leaving ambiguity. The description is minimal and lacks a clear, specific verb+resource combination that defines the tool's exact purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 any context, prerequisites, or exclusions. Given sibling tools like 'dokploy_application_killBuild' and 'dokploy_compose_cancelDeployment', the absence of usage guidelines is a significant gap, leaving the agent to guess based on tool names alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_templatesC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already convey that this is a safe, non-destructive, repeatable operation with open-world semantics. The description adds value by specifying the HTTP method 'GET', implying it's a retrieval operation, which aligns with the annotations. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or pagination, keeping it from a perfect score.

  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 concise with two lines, but it's poorly structured and lacks front-loading of key information. The first line '[compose] compose.templates (GET)' is cryptic, and the parameter listing is minimal. While it avoids unnecessary verbosity, it under-specifies critical details, making it less helpful than a more informative yet concise description would be.

  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 (1 parameter with 0% schema coverage, no output schema) and rich annotations, the description is incomplete. It doesn't explain what 'compose.templates' are, what the tool returns (e.g., a list of templates, their structure), or how the optional 'baseUrl' affects the operation. With annotations covering safety but no output schema, the description should provide more context about the resource and expected outcomes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'baseUrl (string, optional)' under 'Parameters:', but with 0% schema description coverage, it doesn't add meaningful semantics beyond what the schema provides (type and optionality). It fails to explain what 'baseUrl' is used for (e.g., API endpoint override, server context) or provide examples, leaving the parameter's purpose unclear. Since schema coverage is low, the description should compensate more effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[compose] compose.templates (GET)' is vague and tautological, essentially restating the tool name with minimal context. It mentions 'compose.templates' but doesn't specify what action is performed (e.g., list, retrieve, fetch) or what resource is involved (e.g., Docker Compose templates). It fails to distinguish this tool from sibling tools like 'dokploy_compose_create' or 'dokploy_compose_deployTemplate', leaving the purpose unclear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions, nor does it reference sibling tools like 'dokploy_compose_deployTemplate' or 'dokploy_compose_getConvertedCompose' that might be related. This lack of usage context makes it difficult for an agent to determine appropriate invocation scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_deployment_allC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), indicating safe, non-destructive, repeatable operations with open-world assumptions. The description adds minimal context by specifying it's a GET request, which aligns with read-only behavior, but doesn't disclose additional traits like rate limits, authentication needs, or what 'all' entails. With annotations covering key behavioral aspects, the description adds some value but not rich details.

  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 brief and front-loaded with the tool name and HTTP method, but it's under-specified rather than concise. It wastes space on redundant formatting (brackets, parentheses) and lacks essential details, making it inefficient in conveying necessary information.

  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 (deployment operations), lack of output schema, and low parameter coverage, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of deployments), how results are structured, or any limitations, leaving significant gaps for the agent to understand the tool's full context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description lists 'applicationId (string, required)' but doesn't explain what an applicationId is, its format, or where to obtain it. This adds minimal semantics beyond the schema's structural information, failing to compensate for the low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title with minimal additional information ('deployment.all (GET)'), which is essentially a tautology. It doesn't specify what 'all' refers to (e.g., all deployments for an application) or what the tool actually returns, making the purpose vague and not clearly distinguished from sibling tools like 'dokploy_deployment_allByCompose' or 'dokploy_deployment_allByServer'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 lacks context about its intended use case, prerequisites, or comparisons to sibling tools (e.g., other deployment-related tools in the list), leaving the agent with no usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_deployment_allCentralizedC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, non-destructive, repeatable operation that may return varying data. The description adds no behavioral context beyond these annotations, such as rate limits, authentication needs, or what 'allCentralized' entails, but does not contradict the annotations, so it meets the lower bar set by their presence.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[deployment] deployment.allCentralized (GET)'), but this brevity stems from under-specification rather than efficient communication. It lacks essential details like the tool's purpose or usage context, making it ineffective despite its short length. Every sentence should earn its place, but here the single phrase fails to provide meaningful value.

  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 (implied by the 'allCentralized' term and deployment context), the description is incomplete. Annotations cover safety and idempotency, but there is no output schema, and the description does not explain what the tool returns or its scope. Sibling tools suggest it might list deployments, but without clarification, the description leaves significant gaps for an agent to understand its 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?

  The input schema has 0 parameters with 100% description coverage, meaning no parameters need documentation. The description does not add parameter information, which is appropriate here. A baseline of 4 is applied as per the rules for tools with zero parameters, as there is no need to compensate for missing schema details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[deployment] deployment.allCentralized (GET)' is tautological, essentially restating the tool name and title with minimal additional context. It indicates a GET operation on a deployment resource but lacks specificity about what 'allCentralized' means or what resource it operates on, failing to distinguish it from sibling tools like 'dokploy_deployment_all' or 'dokploy_deployment_allByServer'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent with no information to differentiate it from other deployment-related tools in the sibling list, such as 'dokploy_deployment_all' or 'dokploy_deployment_allByType'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_deployment_queueListC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover key behavioral traits (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description's burden is lower. The description adds minimal context by implying it's a GET operation for a queue list, which aligns with annotations. However, it doesn't disclose additional details like rate limits, authentication needs, or what 'queue' specifically entails (e.g., pending deployments). With annotations providing safety and idempotency, a score of 3 reflects some added value but limited behavioral insight.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[deployment] deployment.queueList (GET)'), but this brevity stems from under-specification rather than efficient communication. It fails to front-load key information like purpose or usage, and the bracketed format adds no value. While short, it lacks the structure needed for clarity, making it ineffective as a concise description.

  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 simplicity (0 parameters, rich annotations), the description is incomplete. It doesn't explain what 'queueList' returns (e.g., list of pending deployments), and there's no output schema to compensate. Sibling tools suggest this is part of a deployment system, but the description fails to provide necessary context for the agent to understand the tool's role or output. With annotations covering safety, more descriptive content is needed for full comprehension.

  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 input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's acceptable given the schema's completeness. Baseline for 0 parameters is 4, as the description doesn't need to compensate for any gaps, though it also doesn't enhance understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[deployment] deployment.queueList (GET)' restates the name and title with minimal added meaning. It indicates the tool is related to deployments and queue listing via GET, but lacks a clear verb+resource statement like 'Retrieve the current deployment queue' and doesn't distinguish it from sibling deployment tools (e.g., dokploy_deployment_all, dokploy_deployment_allByType). This is closer to tautology than a purposeful description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, nor does it reference sibling tools like dokploy_deployment_all or dokploy_application_cleanQueues that might handle similar queue-related operations. This leaves the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_destination_oneC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), which already communicate this is a safe, read-only, repeatable operation. The description adds minimal value by specifying '(GET)' which aligns with the annotations, but doesn't provide additional behavioral context like rate limits, authentication requirements, or what specific destination information is returned. No contradiction with annotations exists.

  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 extremely brief (two lines) with zero wasted words, which earns points for conciseness. However, it's under-specified rather than efficiently informative. The structure with 'Parameters:' heading is clear, but the content is insufficient. While technically concise, it fails to provide meaningful information that would help an agent understand and use the tool effectively.

  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 this is a read operation (per annotations) with 1 parameter but 0% schema description coverage and no output schema, the description is inadequate. It doesn't explain what a 'destination' is in this system, what information is returned, or provide any context about the parameter. While annotations cover safety aspects, the description fails to compensate for the lack of schema documentation and output information, leaving significant gaps for an agent trying to use this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for the single parameter 'destinationId'. The description only lists the parameter name without explaining what a destinationId is, its format, where to find it, or its significance. While the description acknowledges the parameter exists, it adds almost no semantic value beyond what's already evident from the schema structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[destination] destination.one (GET)' is tautological - it essentially repeats the tool name 'dokploy_destination_one' with minimal elaboration. While it indicates a GET operation on a 'destination' resource, it doesn't specify what action is performed (e.g., retrieve, fetch, get details) or what a 'destination' represents in this context. The description fails to distinguish this tool from sibling destination tools like 'dokploy_destination_all', 'dokploy_destination_create', etc.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling destination tools (create, remove, testConnection, update, all) but the description offers no context about when this specific 'one' tool is appropriate versus the 'all' tool for listing destinations or other operations. No prerequisites, use cases, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_destination_removeC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true (implying deletion) and readOnlyHint=false (non-read operation), which the description aligns with by implying removal. However, the description adds minimal context beyond annotations—it doesn't specify if removal is permanent, requires permissions, or has side effects. With annotations covering safety, it earns a baseline score for not contradicting them but adds little extra behavioral insight.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets and parentheses) and lacks efficient structuring. While not verbose, it could be more polished and informative without sacrificing conciseness, earning a middling score for being somewhat clear but underdeveloped.

  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 destructive nature (annotations show destructiveHint=true), no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the outcome of removal, error conditions, or dependencies, leaving gaps for a mutation tool. The annotations help but don't fully compensate for the lack of descriptive detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'destinationId' as a required string parameter but provides no semantic details—what a destination ID is, its format, or where to obtain it. This adds minimal value beyond the schema's structural information, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('destination.remove') and adds the HTTP method (POST), which is tautological. It doesn't specify what a 'destination' is in this context or what 'remove' entails beyond deletion. While it mentions the required parameter, it doesn't clarify the action's scope or effect, making the purpose vague.

  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 is provided on when to use this tool versus alternatives. The sibling tools list includes 'dokploy_destination_all', 'dokploy_destination_create', 'dokploy_destination_one', and 'dokploy_destination_update', but the description doesn't differentiate this removal tool from them or indicate prerequisites like needing an existing destination ID.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_docker_getContainersByAppNameMatchC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide good safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the agent knows this is a safe, repeatable query operation. The description adds minimal behavioral context beyond annotations - it specifies HTTP method (GET) and parameter requirements, but doesn't describe what 'match' means (exact, partial, regex), what the output contains, or any constraints like pagination or rate limits.

  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 brief and structured with a parameter list, but it's inefficiently formatted with brackets and redundant information. The '[docker] docker.getContainersByAppNameMatch (GET)' repeats what's already in the name/title. The parameter list is clear but lacks explanatory value. While concise, it fails to use its limited space effectively to convey meaningful information.

  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?

  For a query tool with 3 parameters (one required), 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how matching works, or provide examples of valid inputs. The annotations cover safety aspects, but the description fails to compensate for the missing parameter semantics and output information that an agent needs to use this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description carries full burden for explaining parameters. It lists parameter names and types but provides no semantic meaning: what 'appType' represents, what 'appName' should contain, what 'serverId' identifies, or how these parameters interact. The enum values for appType are listed but not explained. This leaves critical gaps in understanding how to use the parameters effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('docker.getContainersByAppNameMatch') and lists parameters without explaining what the tool actually does. It doesn't specify what 'getContainersByAppNameMatch' means operationally - whether it searches, filters, or retrieves containers matching an app name pattern. This is essentially a tautology of the name with parameter documentation.

  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 is provided about when to use this tool versus alternatives. While sibling tools include several docker-related tools (dokploy_docker_getContainers, dokploy_docker_getContainersByAppLabel, dokploy_docker_getServiceContainersByAppName, dokploy_docker_getStackContainersByAppName), the description doesn't differentiate this tool from them or explain its specific use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_domain_oneC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), indicating a safe, non-destructive, repeatable operation. The description adds minimal value by implying it's a GET request, but doesn't contradict annotations. However, it misses opportunities to clarify rate limits, authentication needs, or response format, which would enhance transparency beyond annotations.

  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 brief but poorly structured and under-specified. It includes a parameter list, which is useful, but the opening phrase '[domain] domain.one (GET)' is cryptic and not front-loaded with clear purpose. While concise, it sacrifices clarity for brevity.

  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 simplicity (1 parameter, no output schema) and rich annotations, the description is incomplete. It doesn't explain what the tool returns, how domainId relates to other domain tools, or any error conditions. Annotations cover safety, but the description lacks necessary operational context for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'domainId (string, required)' without explaining what a domainId is, its format, or where to obtain it. This fails to compensate for the lack of schema descriptions, leaving the parameter's meaning unclear despite the simple single-parameter schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[domain] domain.one (GET)' is vague and tautological, essentially restating the tool name 'dokploy_domain_one' without clarifying what it actually does. It mentions 'domain' and 'GET' but doesn't specify the action (e.g., retrieve, fetch, view) or what resource it operates on, failing to distinguish it from sibling domain tools like 'dokploy_domain_create' or 'dokploy_domain_delete'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites, typical use cases, or comparisons with other domain-related tools (e.g., 'dokploy_domain_byApplicationId'), leaving the agent without any usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitea_giteaProvidersC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, indicating a safe, non-destructive, repeatable operation with open-world semantics. The description adds minimal value by specifying '(GET)', which aligns with read-only behavior but doesn't contradict annotations. However, it lacks additional context like rate limits, authentication needs, or what data is returned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise but under-specified, not efficiently conveying purpose. It consists of a single phrase that repeats the name and title, failing to provide meaningful information. While brief, it doesn't earn its place by adding value, making it more of a placeholder than a helpful description.

  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 simplicity (0 parameters, rich annotations), the description is incomplete. It doesn't explain what 'giteaProviders' are, what data is returned, or how this tool fits into the broader context of Gitea or sibling tools. With no output schema, the description should compensate by clarifying the return values, but it doesn't, leaving gaps in 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?

  The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't add any parameter information, which is acceptable since there are no parameters to explain. A baseline of 4 is appropriate as the schema handles all parameter semantics effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[gitea] gitea.giteaProviders (GET)' is tautological, essentially restating the tool name and title with the addition of '(GET)'. It doesn't specify what the tool actually does (e.g., list, retrieve, or fetch Gitea providers). While it mentions 'giteaProviders', it lacks a clear verb and specific action, making the purpose vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, and given the many sibling tools (e.g., dokploy_gitea_getGiteaRepositories, dokploy_gitea_one), there's no indication of how this tool differs or when it should be selected.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitea_oneC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), which already inform the agent that this is a safe, non-destructive, idempotent read operation. The description adds minimal behavioral context beyond annotations (none explicitly), but since annotations cover key traits well, the bar is lower. No contradiction with annotations exists.

  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 brief but under-specified rather than concise. It wastes space on redundant information (repeating the tool name and HTTP method) without adding value. However, it's structured with a parameter list, which is somewhat organized, but the content is insufficient.

  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 has one parameter with 0% schema coverage, no output schema, and annotations that cover safety but not functional details, the description is incomplete. It lacks essential context like what the tool returns, how the giteaId is used, or its role within the Gitea provider management system, making it inadequate for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists 'giteaId (string, required)' but adds no semantic meaning (e.g., what a giteaId is, where to find it, format examples). This fails to compensate for the schema's lack of documentation, leaving the parameter's purpose unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and HTTP method ('[gitea] gitea.one (GET)') without specifying what the tool actually does. It doesn't provide a clear verb+resource combination (e.g., 'retrieve details about a Gitea provider' or 'get information about a specific Gitea instance'). While it mentions 'gitea' contextually, it's essentially tautological with the name/title.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. Given the sibling tools include 'dokploy_gitea_giteaProviders' (likely for listing multiple providers) and 'dokploy_gitea_getGiteaRepositories' (for repositories), the description offers no differentiation or context for selecting this specific tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_github_githubProvidersC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true) already indicate this is a safe, read-only, idempotent operation with open-world semantics. The description adds no behavioral context beyond these annotations—it doesn't explain what 'githubProviders' entails, potential side effects, or system constraints. However, it does not contradict the annotations, so it meets the lower bar set by existing structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While concise, the description is under-specified—it consists of a single bracketed phrase that fails to convey meaningful information. Conciseness should not come at the cost of clarity; here, the brevity results in a lack of useful content, making it inefficient for an AI agent to understand the tool's function.

  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 simplicity (0 parameters, rich annotations), the description is incomplete. It lacks a clear purpose, usage context, and any explanation of what 'githubProviders' refers to (e.g., configured GitHub integrations in Dokploy). Without an output schema, the description should at least hint at the return type or data structure, but it does not. This leaves significant gaps for an AI agent to infer correct usage.

  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 0 parameters, and schema description coverage is 100%, meaning there are no parameters to document. The description does not need to add parameter semantics, so it appropriately avoids unnecessary details. A baseline score of 4 is applied as the description does not introduce confusion or redundancy regarding parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[github] github.githubProviders (GET)' is tautological—it restates the tool name and adds only the HTTP method. It lacks a specific verb and resource definition, failing to clarify what the tool actually does (e.g., list, retrieve, or manage GitHub providers). Compared to siblings like 'dokploy_github_getGithubBranches', which clearly indicates its purpose, this description provides minimal actionable information.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or related tools (e.g., other provider tools like 'dokploy_bitbucket_bitbucketProviders'). Without any usage instructions, an AI agent cannot determine appropriate scenarios for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitlab_gitlabProvidersC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already indicate this is a safe, read-only, idempotent operation. The description adds no behavioral context beyond what annotations cover (e.g., no rate limits, auth needs, or return format). However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[gitlab] gitlab.gitlabProviders (GET)'), but this brevity stems from under-specification rather than efficient communication. It fails to convey purpose or usage, making it ineffective despite its short length.

  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 simplicity (0 parameters, good annotations), the description is incomplete because it lacks a clear purpose and usage guidelines. While annotations cover safety, the description doesn't explain what the tool returns or its role in the system, leaving gaps for the 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?

  The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter information, but that's acceptable given the absence of parameters. Baseline is 4 for zero parameters, as there's nothing to compensate for.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[gitlab] gitlab.gitlabProviders (GET)' is a tautology that restates the tool name and adds only the HTTP method. It doesn't explain what the tool actually does (e.g., list GitLab providers, retrieve configuration, etc.). While it mentions 'gitlabProviders', it doesn't specify the action or purpose 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or related tools (like other provider tools such as dokploy_bitbucket_bitbucketProviders or dokploy_github_githubProviders). This leaves the agent with no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitProvider_removeC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear behavioral hints: destructiveHint=true indicates permanent deletion, readOnlyHint=false confirms it's a mutation, idempotentHint=false suggests non-idempotent behavior, and openWorldHint=true implies it can handle unknown IDs. The description adds minimal value by specifying 'POST', but doesn't contradict annotations. However, it lacks context on what 'remove' entails (e.g., whether it's reversible, affects linked applications), which would be helpful given the destructive nature.

  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 brief but poorly structured. It includes redundant information like '[gitProvider]' and '(POST)', and uses a bullet point for parameters that adds little value. While not verbose, it lacks front-loaded clarity and wastes space on formatting rather than informative content.

  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 destructive nature (annotations hint at this), one parameter with 0% schema coverage, no output schema, and many sibling tools, the description is incomplete. It doesn't explain the removal's impact, error conditions, or return values, leaving critical gaps for safe agent invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'gitProviderId' as a required parameter without explaining what it is (e.g., an ID from gitProvider_getAll), its format, or where to obtain it. This leaves the single parameter poorly defined, failing to add meaningful semantics beyond the schema's type constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'gitProvider.remove' which is a tautology of the tool name, and includes the HTTP method 'POST' which is redundant with annotations. It doesn't specify what resource is being removed (e.g., a Git provider configuration) or what the removal entails, making the purpose vague. The description fails to distinguish this from sibling tools like 'dokploy_gitProvider_getAll' or other removal tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing gitProviderId), consequences of removal, or what happens to dependent resources. With many sibling tools for managing Git providers (e.g., create, update, testConnection), the lack of usage context is a significant gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_licenseKey_deactivateC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description doesn't contradict these annotations, but adds minimal behavioral context beyond them. It mentions the HTTP method (POST), which suggests a state-changing operation, but doesn't explain what 'deactivate' entails, whether it's reversible, or what permissions might be required. With annotations covering the basic safety profile, the description adds some value but lacks rich behavioral details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise (one line), the description is under-specified rather than efficiently informative. It wastes space on redundant information like the tool name and HTTP method without providing meaningful context. The single sentence doesn't earn its place by adding value beyond what's already obvious from the tool name.

  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 this is a mutation tool (deactivation) with no output schema, the description is inadequate. It doesn't explain what happens when a license key is deactivated, what the expected outcome is, or any side effects. While annotations provide some behavioral hints, the description fails to give the agent enough context to understand the tool's purpose and effects in the broader system.

  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 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters since none exist. It correctly avoids mentioning any parameters, which aligns with the empty input schema. The baseline for 0 parameters is 4, as the description doesn't mislead about parameter requirements.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description "[licenseKey] licenseKey.deactivate (POST)" is essentially a tautology that restates the tool name and adds the HTTP method. It doesn't explain what 'deactivate' means in this context or what resource is being acted upon. While it includes the verb 'deactivate' and resource 'licenseKey', it lacks specificity about what the operation actually does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. There are sibling tools like 'dokploy_licenseKey_activate' and 'dokploy_licenseKey_validate' that appear related, but no context is given about when deactivation is appropriate versus activation or validation. No prerequisites, conditions, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_licenseKey_getEnterpriseSettingsC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the bar is lower. The description doesn't contradict these annotations, but it also adds no behavioral context beyond what's in the annotations—no information about what enterprise settings include, authentication needs, or rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief but not effectively concise—it's under-specified rather than efficiently informative. It wastes characters on redundant information (brackets, HTTP method) without adding value, failing to front-load useful content. A single sentence could have conveyed purpose more clearly.

  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 (likely retrieving configuration settings) and lack of output schema, the description is incomplete. It doesn't explain what enterprise settings are, what format they're returned in, or any dependencies. With annotations covering safety but no output schema, the description should provide more context about the return value.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for any parameter gaps, and it correctly implies no parameters are needed, aligning with the schema. A baseline of 4 is appropriate for zero-parameter tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[licenseKey] licenseKey.getEnterpriseSettings (GET)' is tautological, essentially restating the tool name and HTTP method without specifying what the tool actually does. It mentions 'getEnterpriseSettings' but doesn't explain what enterprise settings are or what resource this operates on, failing to provide meaningful purpose 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like 'dokploy_licenseKey_updateEnterpriseSettings' that clearly serve a different purpose (update vs get), but the description doesn't mention this distinction or any prerequisites, leaving the agent with no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_licenseKey_haveValidLicenseKeyC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide comprehensive behavioral information (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description's burden is lower. However, the description adds no additional behavioral context beyond what's already in annotations - no information about what 'valid' means, what format the response takes, or any edge cases. With good annotations but no description enhancement, a baseline 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise, the description is under-specified rather than efficiently informative. The single line '[licenseKey] licenseKey.haveValidLicenseKey (GET)' wastes space on redundant information (repeating the tool name) while failing to convey meaningful purpose or usage. This isn't true conciseness - it's inadequate specification.

  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 apparent purpose (checking license validity), the description is incomplete. With no output schema and minimal description, an agent wouldn't know what format the response takes (boolean, object, status code), what 'valid' means in this context, or how to interpret results. The annotations help with safety profile, but the functional understanding remains inadequate.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the parameter situation. The description doesn't need to add parameter information, and it doesn't incorrectly suggest parameters exist. With zero parameters, the baseline is 4 even without parameter details in the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[licenseKey] licenseKey.haveValidLicenseKey (GET)' is essentially a tautology that restates the tool name and adds the HTTP method. It doesn't explain what the tool actually does - whether it checks license validity, returns license status, or performs some other operation. The purpose remains unclear beyond the literal name repetition.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include dokploy_licenseKey_activate, dokploy_licenseKey_deactivate, dokploy_licenseKey_getEnterpriseSettings, dokploy_licenseKey_updateEnterpriseSettings, and dokploy_licenseKey_validate, there are clear alternatives but no indication of when this specific tool is appropriate versus those others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_licenseKey_validateC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=false, and openWorldHint=true, which already indicate this is a safe read operation that may have side effects and accepts varied inputs. The description adds minimal value beyond annotations - it implies validation occurs but doesn't describe what validation entails, what happens on success/failure, or any rate limits/auth requirements. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While brief, the description is under-specified rather than concise. It wastes characters on redundant information (tool name, HTTP method) without providing meaningful content. A single bracketed term and method specification don't constitute helpful conciseness when the purpose remains unclear.

  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?

  For a validation tool with no output schema, the description is inadequate. It doesn't explain what validation means, what gets returned (valid/invalid status, license details, error messages?), or how this differs from 'haveValidLicenseKey'. With annotations covering safety but no output schema, the description should explain the validation behavior and results.

  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 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters since there are none. The baseline for 0 parameters is 4, as there's no parameter documentation burden. The description's mention of '[licenseKey]' might imply a parameter, but the schema confirms none exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[licenseKey] licenseKey.validate (POST)' is tautological - it restates the tool name and adds HTTP method without explaining what validation entails. It doesn't specify what resource is being validated (a license key), what validation means (checking validity, expiration, features?), or distinguish from sibling license tools like 'activate', 'deactivate', or 'haveValidLicenseKey'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 versus alternatives. There are multiple sibling license tools (activate, deactivate, haveValidLicenseKey, getEnterpriseSettings, updateEnterpriseSettings) but the description provides no context about when validation is appropriate versus checking validity status or activating/deactivating licenses.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_searchC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations clearly indicate this is a read-only, non-destructive, idempotent, and open-world operation, covering key behavioral traits. The description adds minimal value by noting it's a 'GET' request, which aligns with readOnlyHint=true, but doesn't provide additional context like pagination behavior (implied by limit/offset), error handling, or authentication requirements. Since annotations handle the safety profile adequately, the description's limited contribution warrants a baseline score.

  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 concise but poorly structured. It front-loads minimal information ('[mariadb] mariadb.search (GET)') followed by a parameter list that duplicates the schema without added value. While not verbose, the structure doesn't prioritize helpful context, and the parameter list feels like clutter rather than meaningful elaboration.

  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 (8 optional parameters, no output schema, and schema coverage of 0%), the description is inadequate. It doesn't explain what the tool returns (e.g., a list of MariaDB resources), how results are formatted, or any dependencies. With annotations covering basic behavior but no output schema, the description should provide more context to guide effective use, which it fails to do.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The description lists parameter names but provides no semantic context—e.g., what 'q' searches for, how 'name' or 'appName' filter results, or what 'projectId' and 'environmentId' refer to. This fails to compensate for the schema's lack of documentation, leaving parameters largely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name with minimal context ('[mariadb] mariadb.search (GET)'). It doesn't specify what resource is being searched (e.g., MariaDB databases, instances, or configurations) or what the search operation actually does. While it mentions 'GET' indicating a read operation, this doesn't meaningfully clarify the purpose beyond what's implied by 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?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools list includes other search tools (e.g., dokploy_mariadb_one for fetching a single item, dokploy_application_search for applications), there's no indication of how this tool differs or when it's appropriate. The absence of any usage context leaves the agent to guess based on parameter names alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mongo_removeC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description doesn't explicitly disclose behavioral traits, but it doesn't contradict the annotations either. The annotations indicate this is a destructive (destructiveHint: true), non-read-only (readOnlyHint: false), non-idempotent (idempotentHint: false), and open-world (openWorldHint: true) operation. While the description adds no extra context (e.g., what exactly gets destroyed, authentication needs, or rate limits), the annotations provide clear behavioral information, so the bar is lower. The description's mention of 'POST' aligns with a non-read-only action, but it doesn't add significant value beyond the annotations.

  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 concise with two lines, but it's poorly structured and under-specified. The first line '[mongo] mongo.remove (POST)' is redundant with the name, and the second line merely lists the parameter without explanation. While it avoids unnecessary verbosity, it lacks the front-loaded clarity needed for quick understanding, making it more of a minimal placeholder than an effective description.

  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 as a destructive operation (per annotations) with 1 parameter, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what resource is being removed, the implications of the removal, potential side effects, or what the tool returns. For a mutation tool with significant behavioral hints from annotations, the description should provide more context to guide safe and correct usage, but it falls short.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'mongoId (string, required)' as a parameter, but this adds minimal meaning beyond the input schema, which already specifies 'mongoId' as a required string with minLength: 1. With 0% schema description coverage, the description should compensate by explaining what 'mongoId' represents (e.g., an identifier for a MongoDB instance, database, or document), but it fails to do so. This leaves the parameter semantics unclear and inadequate for proper usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[mongo] mongo.remove (POST)' which is a tautology that essentially restates the tool name 'dokploy_mongo_remove'. It mentions 'mongo' and 'remove' but doesn't specify what resource is being removed (e.g., a MongoDB database, collection, document, or instance). While it implies a deletion operation, it lacks the specificity needed to distinguish it from sibling tools like 'dokploy_mongo_delete' (which doesn't exist but could be similar) or other removal tools in the system.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or comparisons to sibling tools such as 'dokploy_mongo_delete' (if applicable) or other MongoDB-related tools like 'dokploy_mongo_create' or 'dokploy_mongo_update'. Without this information, an AI agent cannot make informed decisions about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mongo_searchC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints (readOnly, non-destructive, idempotent, open-world), and the description does not contradict them—it includes '(GET)', which aligns with read-only behavior. The description adds minimal context (the 'mongo' prefix hints at MongoDB resources), but it lacks details on rate limits, authentication needs, or response format. With annotations covering safety, the description adds some value but not rich behavioral context.

  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 concise but poorly structured—it front-loads with '[mongo] mongo.search (GET)' but then includes a parameter list that duplicates the schema without added value. The parameter section is redundant and could be omitted for better clarity. While brief, it wastes space on schema repetition instead of providing useful guidance.

  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 with 0% schema coverage, no output schema, and annotations that only cover safety, the description is incomplete. It lacks details on what the tool searches (e.g., MongoDB instances, databases), how parameters interact, what the return values are, or any error conditions. For a search tool with many optional filters, this leaves significant gaps in understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (q, name, appName, etc.) but only as a bulleted list without explaining their semantics, relationships, or usage (e.g., 'q' for general search vs. specific filters). This adds minimal meaning beyond the schema, failing to address the coverage gap effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[mongo] mongo.search (GET)' is tautological—it restates the tool name and adds minimal context. It lacks a clear verb-resource statement (e.g., 'Search MongoDB instances' or 'Filter MongoDB databases') and does not distinguish this tool from sibling tools like 'dokploy_mongo_one' or 'dokploy_mongo_update'. The purpose is vague, as it only hints at searching without specifying what is being searched.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, and it fails to reference sibling tools (e.g., 'dokploy_mongo_one' for single instances or 'dokploy_mongo_update' for modifications). This leaves the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mysql_searchC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the agent knows this is a safe, repeatable query operation. The description adds minimal value beyond the GET method indication, but doesn't contradict annotations. No additional behavioral context like pagination behavior, rate limits, or authentication requirements is provided.

  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 brief but inefficiently structured. It wastes space repeating the tool name and HTTP method, then provides a bare parameter list without meaningful explanations. While concise in length, it fails to deliver essential information that would help an agent understand and use the tool effectively.

  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?

  For a search tool with 8 parameters, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain what type of MySQL resources are being searched, what the return format looks like, or how the search parameters interact. The annotations provide safety information, but the description fails to compensate for the missing parameter and output documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for parameter documentation. While it lists all 8 parameters by name, it provides no semantic information about what each parameter does, their relationships, or how they affect search results. For example, it doesn't explain whether 'q' is a general search term or how 'projectId' and 'environmentId' filter results.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name as '[mysql] mysql.search (GET)' without explaining what it searches for or returns. It lists parameters but doesn't state the purpose beyond the tautological 'search'. The name suggests searching MySQL resources, but the description doesn't clarify what type of MySQL entities are being searched.

  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 is provided about when to use this tool versus alternatives. With sibling tools like dokploy_mysql_one, dokploy_mysql_create, and dokploy_mysql_update, the description doesn't explain when search is appropriate versus retrieving a single record or performing other operations. The parameter list implies filtering capabilities but offers no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_createEmailC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond that. It doesn't explain what 'createEmail' entails—e.g., whether it saves a notification configuration, sends a test email, or requires specific permissions. While not contradicting annotations, it fails to supplement them meaningfully for a creation tool.

  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 brief but inefficiently structured—it leads with redundant information (name and HTTP method) and buries the parameter list without context. While not verbose, it wastes space on repetition instead of providing actionable insights, making it under-specified rather than truly concise.

  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 (14 required parameters, no output schema, and annotations only covering basic hints), the description is highly incomplete. It lacks purpose, usage guidelines, parameter explanations, and behavioral details needed for effective tool invocation. For a creation tool with many parameters, this leaves significant gaps in understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists parameter names and types without explaining their meanings. For example, it doesn't clarify what 'appBuildError' or 'serverThreshold' booleans control, or how 'toAddresses' should be formatted. This leaves 14 required parameters largely unexplained, adding minimal value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description only restates the tool name and HTTP method ('notification.createEmail (POST)'), which is tautological. It doesn't explain what the tool actually does—like creating an email notification configuration or setting up email alerts for specific events. The list of parameters hints at functionality but doesn't constitute a clear purpose statement.

  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 is provided on when to use this tool versus alternatives. Sibling tools include other notification creation methods (e.g., createDiscord, createSlack), but the description doesn't differentiate email notifications from these or indicate prerequisites like needing SMTP credentials. Usage is implied only through parameter names, not explicit instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_getEmailProvidersC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description's burden is lower. The description adds no behavioral context beyond what annotations already declare (e.g., no information about rate limits, authentication needs, or return format). However, it doesn't contradict the annotations, and the HTTP method 'GET' aligns with read-only behavior, so it meets the baseline for annotated tools.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While the description is brief, it's under-specified rather than appropriately concise. The single bracketed phrase '[notification] notification.getEmailProviders (GET)' fails to convey meaningful information and wastes space on redundant elements. A truly concise description would use its limited length to state the tool's purpose clearly, which this does not achieve.

  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 simplicity (0 parameters, comprehensive annotations), the description is incomplete. It lacks any explanation of what 'EmailProviders' are, what the return data might look like (no output schema exists), or how this tool relates to other notification tools. While annotations cover safety aspects, the description fails to provide the minimal context needed for an agent to understand when and why to invoke this tool.

  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 0 parameters with 100% schema description coverage (empty schema). With no parameters to document, the description doesn't need to add parameter semantics. The baseline for 0 parameters is 4, as there's nothing to compensate for and no schema gaps to fill.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[notification] notification.getEmailProviders (GET)' is essentially a tautology that restates the tool name and HTTP method. It doesn't specify what the tool actually does (e.g., retrieve available email notification providers, list configured email services) or what resource it operates on. While 'GET' implies retrieval, the purpose remains vague without stating what 'EmailProviders' refers to in this context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include multiple notification-related tools (e.g., dokploy_notification_createEmail, dokploy_notification_testEmailConnection), there's no indication of how this tool fits into the workflow or what prerequisites might be needed. The agent receives no usage context whatsoever.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_oneC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating this is a safe, read-only, idempotent operation. The description adds minimal behavioral context by specifying '(GET)', which aligns with read-only behavior, but doesn't disclose additional traits like rate limits, authentication needs, or what happens if the notificationId doesn't exist. There's no contradiction with annotations, but the description adds little value beyond what annotations already convey.

  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 brief and structured with a header and parameter list, but it's under-specified rather than concise. The first line '[notification] notification.one (GET)' is somewhat redundant with the tool name, and the parameter listing is minimal. While not verbose, it lacks essential information that would make it truly helpful, making it feel incomplete rather than efficiently written.

  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 has 1 parameter with 0% schema coverage, no output schema, and annotations that cover safety but not operational details, the description is incomplete. It doesn't explain what the tool returns (e.g., notification details), error conditions, or how it fits into the broader notification system. For a read operation with a required ID, more context is needed to guide effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'notificationId (string, required)' under 'Parameters:', which adds basic semantics (it's a required string parameter named notificationId). However, it doesn't explain what a notificationId is, its format, where to obtain it, or any constraints beyond the schema's minLength=1. This is insufficient for a tool with 0% schema coverage, leaving the parameter poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[notification] notification.one (GET)' which partially indicates it's a GET operation on a notification resource, but it's vague and tautological - it essentially restates the name/title 'dokploy_notification_one' without specifying what the tool actually does (e.g., retrieve, fetch, or view a specific notification). It doesn't clearly distinguish from sibling notification tools like 'dokploy_notification_all' or 'dokploy_notification_createCustom'.

  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 guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or differentiate it from other notification-related tools in the sibling list (e.g., when to use this versus 'dokploy_notification_all' for listing all notifications). The parameter list implies it requires a notificationId, but no usage context is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_testNtfyConnectionC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond what annotations provide (e.g., no mention of what 'testing connection' entails, expected outcomes, or side effects). However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  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 brief but inefficiently structured. It includes redundant information (tool name and HTTP method) and a parameter list that doesn't add explanatory value. While not verbose, it fails to front-load essential purpose, making it less helpful than a more informative single sentence would be.

  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 4 parameters with 0% schema coverage, no output schema, and annotations that don't explain the tool's function, the description is incomplete. It lacks critical context: what the tool does, expected results, error conditions, or how parameters relate to Ntfy notification testing. This is inadequate for a connection-testing tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameter names and types but provides no semantic meaning (e.g., what 'serverUrl', 'topic', 'accessToken', or 'priority' represent in Ntfy context). This adds minimal value beyond the schema's structural information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('notification.testNtfyConnection') and HTTP method ('POST') but doesn't specify what the tool actually does. It lists parameters but doesn't explain the action (e.g., 'tests connection to an Ntfy notification service'). This is tautological rather than clarifying purpose.

  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 versus alternatives. While sibling tools include other notification test tools (e.g., testDiscordConnection, testEmailConnection), the description doesn't mention Ntfy-specific context or differentiate from them. Usage is implied only by the parameter list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_activeC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, indicating a safe, non-destructive, repeatable operation that may return partial data. The description adds no behavioral context beyond this (e.g., what 'active' means, response format, or error conditions). However, since annotations cover key safety aspects, the bar is lower, and the description does not contradict them, warranting a baseline score for minimal added value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[organization] organization.active (GET)'), but this brevity stems from under-specification rather than efficient communication. It fails to convey meaningful information in its single phrase, making it ineffective despite its short length. A concise description should be informative, not minimalistic to the point of being unhelpful.

  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 (implied by the 'organization' context and sibling tools) and the absence of an output schema, the description is incomplete. It does not explain what the tool returns (e.g., a boolean status, organization details, or a list), leaving the agent guessing. While annotations provide safety hints, the description lacks essential operational context, making it inadequate for informed use.

  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 input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate here. Since there are no parameters to explain, the description does not need to compensate, and a baseline score of 4 is justified as it avoids misleading or redundant information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[organization] organization.active (GET)' is tautological, essentially restating the tool name and title with an HTTP method. It does not specify what the tool actually does (e.g., check if an organization is active, retrieve active organization status, or list active organizations). While it includes a verb ('GET'), it lacks a clear resource or action, making the purpose vague and indistinguishable from sibling tools like 'dokploy_organization_all' or 'dokploy_organization_one'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or comparisons to sibling tools (e.g., 'dokploy_organization_all' for listing all organizations or 'dokploy_organization_one' for retrieving a specific organization). Without such information, an agent cannot determine appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_allC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, indicating a safe, repeatable read operation. The description adds no behavioral context beyond these annotations—it doesn't explain what 'all' entails (e.g., pagination, filtering, or return format). However, it does not contradict the annotations, so the score reflects minimal added value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise but under-specified—it's a single bracketed phrase that fails to convey meaningful information. While brief, it lacks substance and does not front-load useful details, making it ineffective rather than efficiently concise.

  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 simplicity (0 parameters, rich annotations), the description is incomplete. It does not explain what 'all' means (e.g., returns a list of organizations, possibly with details) or address output expectations, and there is no output schema. For a tool that likely returns data, more context on the return value is needed despite the annotations.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add any parameter information, but with no parameters, the baseline is 4 as the schema fully covers the absence of inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[organization] organization.all (GET)' is tautological—it essentially restates the tool name 'dokploy_organization_all' with minor formatting. It does not specify what the tool actually does (e.g., list all organizations, retrieve organization details) or distinguish it from sibling tools like 'dokploy_organization_one' or 'dokploy_organization_active'. This provides minimal clarity beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it reference sibling tools (e.g., 'dokploy_organization_one' for a single organization or 'dokploy_organization_active' for active ones). This leaves the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_allInvitationsC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide strong behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds minimal value by indicating it's a GET operation, which aligns with read-only behavior. However, it does not disclose additional traits like pagination, rate limits, authentication needs, or what 'allInvitations' encompasses (e.g., pending vs. all). With annotations covering safety and idempotency, the description meets a baseline but lacks enriching context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise but under-specified, not efficiently informative. It consists of a single bracketed phrase that repeats the name and adds '(GET)', failing to front-load actionable information. While brief, it lacks substance, making it inefficient for agent understanding rather than a model of clarity.

  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 simplicity (0 parameters, annotations provided, no output schema), the description is incomplete. It does not explain what 'allInvitations' returns (e.g., list structure, invitation details), any organizational scope, or potential side effects. While annotations cover basic safety, the description fails to provide sufficient context for an agent to use the tool effectively without guessing.

  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 input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate. A baseline of 3 is set for high schema coverage, but the absence of parameters elevates the score as there is nothing to compensate for, making the description adequate in this dimension.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[organization] organization.allInvitations (GET)' is tautological, essentially restating the tool name and title with minimal added context. It specifies the HTTP method (GET) but lacks a clear, specific verb-resource statement explaining what the tool actually does (e.g., 'Retrieve all pending invitations for an organization'). This fails to distinguish it from sibling tools like 'dokploy_organization_inviteMember' or 'dokploy_organization_removeInvitation' 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., organization context), exclusions, or related tools (e.g., 'dokploy_user_getInvitations' for user-specific invitations). Without any usage context, an agent cannot determine appropriate invocation scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_oneC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide comprehensive behavioral information (read-only, non-destructive, idempotent, open-world). The description adds minimal value by specifying it's a GET operation, which aligns with the readOnlyHint annotation. While it doesn't add significant context beyond annotations, it doesn't contradict them either, and the annotations themselves are quite informative.

  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 extremely concise - arguably too concise. While it wastes no words, it's under-specified rather than efficiently informative. The two-line structure (method + parameter list) is clear but lacks substantive content. Every sentence should earn its place, and here the content is insufficient rather than efficiently packed.

  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 organization management systems and the lack of output schema, the description is incomplete. While annotations cover safety aspects, the description doesn't explain what information is returned about an organization, what authentication might be required, or how this fits into the broader organizational workflow. For a tool that presumably retrieves specific organization data, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage for the single required parameter 'organizationId', the description provides no additional semantic information about this parameter. It doesn't explain what constitutes a valid organization ID, where to find it, or what format it should be in. The description merely lists the parameter name without any meaningful context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is a tautology that essentially restates the tool name ('organization.one') and adds the HTTP method (GET). It doesn't specify what the tool actually does - whether it retrieves organization details, settings, members, or something else. While it mentions 'organization' as the resource, the purpose remains vague beyond being a GET operation on an organization.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'dokploy_organization_all', 'dokploy_organization_active', 'dokploy_organization_update', and 'dokploy_organization_delete', there's no indication of when this specific 'one' operation is appropriate versus listing all organizations or performing other organization-related actions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_deleteC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear behavioral hints: destructiveHint=true indicates data removal, readOnlyHint=false confirms mutation, idempotentHint=false suggests non-idempotent behavior, and openWorldHint=true implies flexible input. The description adds minimal context by specifying the HTTP method (POST), which is useful but doesn't contradict annotations. However, it lacks details on permissions, side effects, or error conditions that would enrich understanding beyond annotations.

  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 brief with two lines, but it's inefficiently structured. The first line '[patch] patch.delete (POST)' is redundant with the tool name and title, and the parameter listing adds little semantic value. While concise, it wastes space on repetition rather than providing useful information, making it under-specified rather than optimally concise.

  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 destructive nature (destructiveHint=true), no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what a patch is, the consequences of deletion, potential return values, or error handling. For a mutation tool with significant behavioral implications, this leaves critical gaps in understanding how to invoke it safely and effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'patchId (string, required)' but provides no semantic meaning—what a patchId is, where to find it, or format constraints. The description repeats the parameter name without adding value beyond the schema's structural definition, failing to clarify usage or context for the single required parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[patch] patch.delete (POST)' which is a tautology of the tool name 'dokploy_patch_delete' and doesn't clarify what a 'patch' resource is or what deletion entails. It provides the verb 'delete' but lacks specificity about the resource scope or effect. Sibling tools like 'dokploy_patch_one' and 'dokploy_patch_create' suggest this is part of a patch management system, but the description doesn't differentiate this tool from them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are multiple patch-related sibling tools (e.g., 'dokploy_patch_create', 'dokploy_patch_one', 'dokploy_patch_update'), but the description doesn't indicate when deletion is appropriate, what prerequisites might exist, or what happens after deletion. This leaves the agent with no contextual usage information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_port_deleteC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, confirming this is a destructive write operation. The description adds value by specifying the HTTP method (POST), which isn't covered by annotations. However, it lacks details on side effects (e.g., impact on associated services), permissions, or error conditions. No contradiction with annotations exists.

  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 brief but under-specified—it wastes space on redundant formatting (brackets, parentheses) and a parameter list that repeats schema info without adding context. It's front-loaded with the tool name but lacks efficiency; every sentence doesn't earn its place due to missing explanatory value.

  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 destructive nature (annotations hint at this), single parameter with 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain the resource ('port'), the deletion's consequences, or expected outcomes. For a destructive tool, more context is needed to ensure safe usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'portId' as a required string without explaining what a portId is, its format, or where to obtain it. This adds minimal meaning beyond the schema's type and requirement, failing to address the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('port.delete') without explaining what a 'port' is in this context or what deletion entails. It mentions the HTTP method (POST) and lists the parameter, but doesn't clarify the action's purpose beyond the tautological 'delete'. Compared to siblings like 'dokploy_port_create' and 'dokploy_port_update', it doesn't differentiate the specific resource or scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing port), exclusions, or related tools like 'dokploy_port_one' (likely for viewing) or 'dokploy_port_create'. The agent must infer usage from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_port_oneC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already inform the agent this is a safe, repeatable read operation. The description adds minimal value by specifying the HTTP method (GET), but doesn't contradict annotations or provide additional behavioral context like rate limits, authentication needs, or what happens if the portId doesn't exist.

  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 extremely brief but not appropriately structured. It's just a label and parameter listing without a clear purpose sentence. While concise, it lacks the front-loaded clarity needed for an agent to quickly understand the tool's function.

  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 has no output schema and 0% schema description coverage, the description is insufficient. It doesn't explain what the tool returns (e.g., port details, status), leaving the agent guessing. For a read operation with one parameter, more context about the return value and parameter meaning is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'portId (string, required)' without explaining what a portId is, its format, or where to find it. This adds no meaningful semantics beyond what the bare schema already provides (a required string parameter).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('port.one') and verb ('GET') without specifying what resource it retrieves or what 'port' refers to in this context. It's a tautology that doesn't distinguish this tool from its siblings (like dokploy_port_create, dokploy_port_delete, dokploy_port_update).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or when-not-to-use scenarios. Given the sibling tools include create/delete/update operations for ports, this appears to be a read operation, but this isn't explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_project_allC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation with potentially open-ended results. The description adds no additional behavioral context beyond what annotations already convey, such as rate limits, authentication needs, or pagination details. However, it does not contradict the annotations, so it meets the lower bar set by their presence without adding significant value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description '[project] project.all (GET)' is extremely brief but under-specified rather than concise. It uses minimal words but fails to convey essential information, making it inefficient in communicating the tool's purpose. While it avoids unnecessary elaboration, it sacrifices clarity, so it does not earn a high score for conciseness.

  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 simplicity (0 parameters, no output schema) and rich annotations, the description is incomplete. It lacks details on what 'all' means (e.g., whether it returns a list, the format, or any limitations), which is crucial even for a read-only tool. Without an output schema, the description should ideally hint at return values, but it does not, leaving gaps in understanding the tool's 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?

  The input schema has 0 parameters with 100% description coverage, meaning no parameters are documented because none exist. The description does not mention parameters, which is appropriate here. Given the baseline of 4 for zero parameters, the score reflects that the description does not need to compensate for any parameter documentation gaps, as there are none to address.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[project] project.all (GET)' is tautological, essentially restating the tool name 'dokploy_project_all' with minimal formatting. It does not clearly articulate what the tool does beyond implying a GET operation on projects, lacking specificity about what 'all' entails (e.g., listing, retrieving, or enumerating projects). This fails to distinguish it from sibling tools like 'dokploy_project_one' or 'dokploy_project_search', leaving the purpose vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it reference sibling tools like 'dokploy_project_one' for single projects or 'dokploy_project_search' for filtered searches. This absence of usage instructions makes it challenging for an AI agent to determine appropriate application scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_project_allForPermissionsC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide comprehensive behavioral information (read-only, non-destructive, idempotent, open-world), so the description doesn't need to repeat these. However, the description adds minimal value beyond annotations - it only indicates this is a GET operation, which is already implied by readOnlyHint. It doesn't provide any additional context about what 'allForPermissions' means behaviorally, such as what data is returned or how permissions are structured.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While the description is technically concise (one short phrase), it's under-specified rather than efficiently informative. The single bracketed phrase '[project] project.allForPermissions (GET)' doesn't provide meaningful information - it's essentially just repeating the tool name with formatting. This isn't true conciseness but rather insufficient content.

  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 purpose (apparently related to projects and permissions), the description is inadequate. With no output schema and annotations that only cover safety/behavioral aspects, the description should explain what this tool returns and what 'allForPermissions' means. The current description leaves the agent guessing about the tool's actual function and output format.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of parameters. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters. With no parameters to document, a baseline score of 4 is appropriate since there's nothing missing.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[project] project.allForPermissions (GET)' is a tautology that restates the tool name and adds the HTTP method, but it doesn't explain what the tool actually does. It mentions 'project' and 'allForPermissions' but doesn't specify what 'allForPermissions' means - whether it lists projects for permission purposes, retrieves all permissions for projects, or something else. This is vague and doesn't distinguish it from sibling tools like 'dokploy_project_all'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this tool should be used, when it shouldn't be used, or what alternatives exist among the many sibling tools. For example, it doesn't clarify how this differs from 'dokploy_project_all' or 'dokploy_user_getPermissions' which might be related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_project_removeC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a destructive, non-idempotent, open-world mutation tool. The description doesn't contradict these but adds minimal context beyond the name—it doesn't explain what 'remove' entails (e.g., permanent deletion, cascading effects, or confirmation steps). Given annotations cover the safety profile, the description adds some value by implying deletion but lacks behavioral details like error conditions or side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is under-specified rather than concise. It includes redundant formatting (brackets, 'POST') and a parameter list that doesn't add value, wasting space that could be used for meaningful guidance. The structure is not front-loaded with critical information, making it inefficient.

  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?

  For a destructive tool with no output schema and 0% schema coverage, the description is inadequate. It doesn't explain the outcome (e.g., success confirmation, error messages), potential impacts, or recovery options. Given the high stakes of removal operations, more context is needed to ensure safe usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'projectId' as a required parameter without explaining what it is (e.g., a UUID, name, or how to obtain it). This adds little meaning beyond the schema's structural requirement, failing to clarify the parameter's purpose or format.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a project ('project.remove'), which is a specific verb+resource. However, it doesn't distinguish this from other destructive sibling tools like 'dokploy_application_delete' or 'dokploy_compose_delete', leaving ambiguity about what exactly a 'project' is in this context compared to other deletable entities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the project must be stopped first), what happens to associated resources, or when not to use it (e.g., if you need to archive instead). With many sibling deletion tools, this lack of differentiation is a significant gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_project_searchC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description doesn't need to repeat these. However, the description adds no behavioral context beyond what's in annotations - no information about pagination behavior (implied by limit/offset but not explained), rate limits, authentication requirements, or what happens when no results are found. With good annotations, the baseline is met but no additional value is added.

  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 technically concise but poorly structured. It front-loads the tool name in brackets but wastes space on redundant formatting. The parameter listing is bulleted but provides minimal value. While not verbose, the structure doesn't effectively communicate essential information - it's more of a technical specification than a helpful description.

  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?

  For a search tool with 5 parameters, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how results are formatted, whether it supports pagination (implied by limit/offset but not explained), or error conditions. The annotations provide safety information but the functional context is missing, making it difficult for an agent to use this tool effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description simply lists parameter names and types without explaining what they do, how they interact, or providing examples. 'q' versus 'name' and 'description' parameters are particularly confusing without explanation. The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('project.search') without explaining what it actually does. It provides a verb ('search') and resource ('project') but lacks specificity about what kind of projects or what search functionality is offered. This is borderline tautological since it essentially repeats the name/title without meaningful elaboration.

  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 is provided on when to use this tool versus alternatives. The sibling tools list includes 'dokploy_project_all' and 'dokploy_project_one', which are clearly related project tools, but the description doesn't differentiate this search tool from those list or get operations. There's no mention of prerequisites, context, or comparison to siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redirects_deleteC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear behavioral hints (destructiveHint: true, readOnlyHint: false, idempotentHint: false, openWorldHint: true). The description doesn't contradict these annotations and adds minimal context about being a POST operation. However, it doesn't provide additional behavioral details like what happens after deletion, error conditions, or confirmation requirements.

  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 extremely concise (two lines) but under-specified rather than efficiently informative. The first line '[redirects] redirects.delete (POST)' is redundant with the tool name, and the parameter listing is minimal. While not verbose, it fails to provide essential context that would help an agent.

  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?

  For a destructive deletion tool with 1 parameter and 0% schema description coverage, the description is inadequate. It lacks information about what 'redirects' are in this system, what deletion entails, potential side effects, or how to identify the correct redirectId. With no output schema and minimal annotations beyond safety hints, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full burden for parameter documentation. It only lists 'redirectId (string, required)' without explaining what a redirectId is, how to obtain it, its format, or examples. This provides minimal value beyond what the bare schema already indicates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'redirects.delete (POST)' which restates the tool name/action without adding meaningful context. It doesn't specify what resource is being deleted (redirect rules? URL redirects?) or what 'redirects' refers to in this system. While it includes 'POST' as the method, this is redundant with the tool name's 'delete' action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. There are sibling tools like 'dokploy_redirects_create', 'dokploy_redirects_one', and 'dokploy_redirects_update', but the description doesn't explain how this deletion tool relates to them or when deletion is appropriate versus updating.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_searchC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as read-only, non-destructive, idempotent, and open-world, covering key safety and idempotency traits. The description adds minimal behavioral context (just 'GET'), but doesn't contradict annotations. However, it fails to describe important behaviors like pagination (implied by limit/offset but not explained), response format, or error conditions, leaving gaps despite good annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise but poorly structured. It front-loads minimal information ('[redis] redis.search (GET)') and then lists parameters without integration into explanatory text. While not verbose, the structure doesn't effectively communicate purpose or usage, making it inefficient despite its brevity.

  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 with 0% schema coverage, no output schema, and annotations that only cover safety/idempotency, the description is incomplete. It doesn't explain what the tool returns (e.g., list of Redis instances with fields), how pagination works with limit/offset, or error handling. For a search tool with many filtering options, this leaves the agent poorly equipped to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 merely lists parameter names without explaining their purpose, relationships, or how they affect the search. For example, it doesn't clarify if 'q' is a general query string, how 'name', 'appName', 'description' filter results, or what 'projectId' and 'environmentId' scope. With 8 parameters, this lack of semantic explanation is a significant gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is tautological, essentially restating the tool name 'redis.search' with 'GET' in parentheses. It doesn't specify what resource is being searched (Redis instances? configurations? data?), nor what 'search' means in this context. While it mentions 'redis' in brackets, this adds minimal clarity beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'dokploy_redis_one' (likely for retrieving a single Redis instance) and other search tools (e.g., 'dokploy_application_search'), there's no indication of when this specific Redis search is appropriate, what prerequisites exist, or what distinguishes it from other search operations in the system.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_registry_allC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover key behavioral traits: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, non-destructive, repeatable read operation with open-ended results. The description adds minimal value by specifying 'GET', which aligns with annotations but doesn't provide additional context like rate limits, authentication needs, or output format. No contradiction exists, but the description is redundant given the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of being cryptic. It consists of a single bracketed phrase with no full sentences, failing to communicate purpose effectively. While brevity can be good, this lacks structure and clarity, making it difficult for an agent to understand without external context.

  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 simplicity (0 parameters, no output schema) and rich annotations, the description is incomplete. It doesn't explain what 'registry.all' retrieves, the scope of results, or any limitations. While annotations provide safety and idempotency, the description fails to add meaningful context, leaving gaps in understanding the tool's function and output.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't add parameter details, which is unnecessary here. A baseline of 4 is appropriate as no parameters exist, and the schema adequately covers this.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[registry] registry.all (GET)' is tautological, essentially restating the tool name with minimal context. It mentions 'registry' and 'all' but doesn't specify what it retrieves (e.g., list of registries, registry entries, or configurations). While it implies a GET operation, it lacks a clear verb-resource combination that distinguishes it from sibling tools like 'dokploy_registry_one' or 'dokploy_registry_create'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools (e.g., 'dokploy_registry_one' for a single registry or 'dokploy_registry_create' for creating registries). This leaves the agent without direction on appropriate scenarios for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_registry_removeC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=false (write operation), destructiveHint=true (permanent deletion), idempotentHint=false (non-idempotent), openWorldHint=true (may create new resources). The description doesn't contradict these but adds minimal behavioral context (e.g., it's a POST request). However, it fails to elaborate on critical aspects like what 'remove' entails (e.g., data loss, side effects) or error conditions, which would be valuable given the destructive nature. Since annotations cover core traits, the description adds some but not comprehensive behavioral insight.

  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 brief but poorly structured. It includes the tool path ('[registry] registry.remove') and HTTP method, which is useful, but the parameter listing is redundant with the schema and lacks explanatory text. While concise, it's under-specified rather than efficiently informative, with wasted space on a basic parameter restatement that doesn't add value.

  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 destructive nature (destructiveHint=true), one parameter with 0% schema coverage, no output schema, and complex sibling tools, the description is inadequate. It doesn't explain the outcome of removal, potential dependencies, or error handling. For a mutation tool with significant behavioral implications, more context is needed to guide safe and correct usage, especially without output schema details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description lists 'registryId (string, required)' but doesn't explain what a registryId is, its format, where to obtain it, or validation rules. This leaves the parameter's meaning ambiguous, failing to compensate for the lack of schema documentation. With one parameter and no schema descriptions, the description should provide more semantic context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('registry.remove') and provides minimal context about what it does. It mentions 'Parameters:' but doesn't explain what 'remove' actually means in this context (e.g., deleting a registry entry, unregistering a container registry). While it includes the HTTP method (POST), it lacks a clear verb+resource statement that distinguishes it from sibling tools like 'dokploy_registry_all' or 'dokploy_registry_create'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 doesn't mention prerequisites (e.g., needing an existing registryId), when it's appropriate to remove a registry, or what happens after removal. It also fails to reference sibling tools like 'dokploy_registry_all' for listing registries or 'dokploy_registry_create' for creating one, leaving the agent with no context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_schedule_listC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true) already indicate this is a safe, read-only, idempotent operation. The description adds no behavioral context beyond what annotations provide, such as what data is returned, pagination, or error conditions. No contradiction exists, but minimal value is added.

  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 brief but poorly structured. It includes a redundant header ('[schedule] schedule.list (GET)') and a parameter list without context. While concise, it lacks effective front-loading of purpose and wastes space on formatting rather than informative content.

  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 2 parameters with 0% schema coverage, no output schema, and annotations covering basic safety, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of schedules), how results are formatted, or any limitations. For a list operation with undocumented inputs, this leaves significant gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters (id, scheduleType) but doesn't explain their meaning (e.g., what 'id' refers to, what the scheduleType enum values represent). It fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('schedule.list') without explaining what 'list' means in this context. It mentions parameters but doesn't state what the tool actually does (e.g., retrieve schedules for a specific resource). This is a tautology that provides minimal clarification 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 is provided on when to use this tool versus alternatives. With many sibling tools (e.g., dokploy_schedule_one, dokploy_schedule_create), the description doesn't differentiate this list operation from other schedule-related tools or indicate prerequisites like required permissions or context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_countC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation. The description adds minimal value by implying a GET request, which aligns with the annotations but doesn't provide additional behavioral context (e.g., what 'count' entails, format of the count, or any limitations). No contradiction with annotations exists, but the description doesn't enrich understanding beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description '[server] server.count (GET)' is extremely brief but not effectively concise—it's under-specified rather than efficiently informative. It uses minimal words but fails to convey meaningful information, making it more of a placeholder than a helpful description. While it's front-loaded (the only content), it doesn't earn its place by adding value.

  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 simplicity (0 parameters, annotations present, no output schema), the description is incomplete. It doesn't explain what 'count' refers to (e.g., total servers, active instances), the return format, or any contextual details needed for an agent to understand the tool's output. Annotations cover safety, but the description lacks essential operational context, making it inadequate for effective use.

  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 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, and it doesn't introduce any confusion. A baseline of 4 is appropriate as there are no parameters to document, and the description doesn't detract from this.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[server] server.count (GET)' is tautological, essentially restating the tool name 'dokploy_server_count' in a different format. It mentions 'server' and 'count' but doesn't specify what is being counted (e.g., servers, instances, resources) or provide a clear verb-action. While it hints at counting something related to servers, it lacks specificity and doesn't distinguish from siblings like 'dokploy_server_all' or 'dokploy_server_one'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 provides no context about its purpose, prerequisites, or comparisons to sibling tools (e.g., 'dokploy_server_all' for listing servers). This leaves the agent with no information to make an informed selection among similar server-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_getServerMetricsC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds value by specifying the HTTP method (GET), which isn't covered by annotations. However, it doesn't describe behavioral aspects like rate limits, authentication needs beyond the token parameter, or what the metrics output looks like.

  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 brief and front-loaded with the tool name and HTTP method, but it wastes space on a redundant parameter list that adds no value beyond the schema. The structure is minimal but not optimally efficient; it could be more concise by omitting the parameter enumeration and instead explaining their purposes.

  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 (3 parameters with 0% schema coverage, no output schema), the description is inadequate. It fails to explain what metrics are retrieved, the format of the response, or how parameters like 'dataPoints' should be used. Annotations cover safety, but the description lacks essential operational context for a metrics retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameter names (url, token, dataPoints) but provides no semantic context—what these parameters represent, their formats, or examples. For instance, 'dataPoints' is undocumented; it could be a comma-separated list, JSON, or something else. This leaves critical gaps for proper tool invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('server.getServerMetrics') and lists parameters without explaining what the tool actually does. It doesn't specify what server metrics are retrieved (e.g., CPU, memory, disk usage) or what resource is being measured. This is a tautology that provides minimal value 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any sibling tools (like dokploy_server_getServerTime or dokploy_user_getServerMetrics) that might serve similar purposes, nor does it specify prerequisites or appropriate contexts for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_publicIpC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description does not contradict these, as 'GET' aligns with read-only behavior. However, it adds no behavioral context beyond what annotations already cover, such as rate limits, authentication needs, or output format. With annotations doing the heavy lifting, the description's minimal addition warrants a baseline score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description '[server] server.publicIp (GET)' is overly terse and lacks structure. It fails to front-load key information in a complete sentence, making it inefficient for quick understanding. While brief, it under-specifies rather than being concise, as it omits essential context that would help an agent.

  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 simplicity (0 parameters, annotations provided), the description is incomplete. It does not explain what the tool returns (e.g., the public IP address as a string or object), and there is no output schema. For a read-only tool, the description should clarify the return value to aid the agent, but it leaves this ambiguous.

  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 input schema has 0 parameters with 100% coverage, meaning no parameters are documented. The description does not add parameter information, which is appropriate since none exist. Given the absence of parameters, the baseline score is 4, as there is no need to compensate for missing schema details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[server] server.publicIp (GET)' is a tautology that restates the name and title with minimal added meaning. It vaguely indicates a GET operation related to a server's public IP, but lacks a clear verb (e.g., 'retrieve' or 'fetch') and does not specify what resource it acts upon or distinguish it from sibling tools like 'dokploy_server_getServerMetrics' or 'dokploy_settings_getIp'. This provides insufficient clarity for an agent to understand its specific function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'dokploy_settings_getIp' for general IP retrieval or 'dokploy_server_getServerMetrics' for server data), there is no indication of context, prerequisites, or exclusions. This leaves the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanAllDeploymentQueueC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, which already convey that this is a non-read-only, destructive, non-idempotent operation with open-world semantics. The description adds no behavioral context beyond these annotations, such as what gets destroyed, side effects, or rate limits. However, it does not contradict the annotations, so it meets the lower bar set by having annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[settings] settings.cleanAllDeploymentQueue (POST)'), but this brevity stems from under-specification rather than efficient communication. It fails to convey essential information, making it ineffective despite its short length. Every sentence (or lack thereof) does not earn its place in aiding tool selection.

  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 implied by 'cleanAllDeploymentQueue' (likely a destructive operation on a deployment queue), the description is insufficient. Annotations provide some behavioral hints, but there is no output schema, and the description lacks details on what the tool does, its effects, or return values. For a destructive tool with no output schema, more context is needed to be 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?

  The tool has 0 parameters with 100% schema description coverage, so the input schema fully documents the absence of parameters. The description does not add any parameter information, which is acceptable given the baseline of 4 for zero parameters, as there is nothing to compensate for.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.cleanAllDeploymentQueue (POST)' is tautological, essentially restating the tool name and HTTP method without explaining what the tool actually does. It mentions 'settings' and 'cleanAllDeploymentQueue' but doesn't specify the action (e.g., clearing, resetting, or removing items) or the resource (deployment queue) in a meaningful way. This provides minimal clarity beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 lacks context, prerequisites, or comparisons to sibling tools like 'dokploy_application_cleanQueues' or 'dokploy_compose_cleanQueues'. Without any usage instructions, an AI agent cannot determine appropriate scenarios for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanDockerBuilderC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true, idempotentHint=false, and openWorldHint=true, which the description doesn't contradict. However, it adds no behavioral context beyond what annotations provide—such as what exactly gets destroyed (e.g., Docker builder cache, artifacts), potential side effects, or permissions required. Since annotations cover safety traits, the bar is lower, but the description misses opportunities to clarify the destructive nature.

  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 brief but poorly structured—it's essentially a label with a parameter list. While not verbose, it lacks a clear, front-loaded explanation of the tool's purpose. The formatting as a code-like snippet doesn't aid readability, but it avoids unnecessary fluff.

  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 destructive nature (per annotations), no output schema, and low parameter coverage, the description is inadequate. It doesn't explain what the tool returns, error conditions, or the scope of cleanup. For a destructive operation with potential system impact, more context is needed to guide safe usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description lists 'serverId' as optional but provides no semantic meaning—what server it refers to, default behavior if omitted, or impact on the cleanup operation. With one parameter and no schema descriptions, the description fails to compensate, leaving the parameter's purpose ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name/title ('settings.cleanDockerBuilder') and adds only the HTTP method (POST), which is tautological. It doesn't explain what 'cleanDockerBuilder' means—whether it clears cache, removes temporary files, or deletes builder instances. The verb 'clean' is vague, and the resource 'DockerBuilder' is unclear without context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. Among siblings, there are other cleanup tools (e.g., dokploy_settings_cleanAll, dokploy_settings_cleanDockerPrune), but the description doesn't differentiate this one's specific purpose or prerequisites. This leaves the agent guessing about appropriate contexts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanMonitoringC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, which already convey that this is a non-idempotent, destructive write operation. The description adds minimal behavioral context beyond this, as it doesn't explain what 'cleanMonitoring' entails (e.g., whether it deletes logs, resets metrics, or removes monitoring configurations). However, it doesn't contradict the annotations, so it avoids a lower score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[settings] settings.cleanMonitoring (POST)'), but this brevity stems from under-specification rather than efficient communication. It fails to convey essential information about the tool's purpose or usage, making it ineffective despite its short length. It's not front-loaded with useful details, just a restatement of metadata.

  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 destructive nature (annotations show destructiveHint=true) and lack of output schema, the description is insufficient. It doesn't explain what 'cleanMonitoring' does, what data is affected, or what the expected outcome is. For a destructive operation with no output schema, more context is needed to guide safe usage, but the description provides almost none.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as there's nothing to compensate for, and the description doesn't mislead about inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.cleanMonitoring (POST)' is tautological, essentially restating the tool name and title with minimal added context. It mentions 'cleanMonitoring' but doesn't specify what this operation actually does (e.g., what data is cleaned, what monitoring is affected). While it hints at a settings-related cleanup, it lacks a clear verb-resource-action statement that distinguishes it from siblings like 'dokploy_settings_cleanAll' or 'dokploy_settings_cleanRedis'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or compare it to sibling tools (e.g., 'dokploy_settings_cleanAll' or 'dokploy_settings_cleanRedis'), leaving the agent with no context for selection. This omission is critical given the many cleanup-related tools in the sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanSSHPrivateKeyC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description does not contradict. However, the description adds no behavioral context beyond what annotations provide, such as what 'clean' entails (e.g., deletion, removal, or resetting of SSH private keys) or any side effects like data loss or system impact.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of being cryptic, consisting of a single bracketed phrase. It lacks proper sentence structure and fails to front-load essential information, making it inefficient for quick understanding.

  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 destructive nature (destructiveHint=true) and lack of output schema, the description is incomplete. It does not explain the outcome, such as what 'clean' means or what happens post-execution, leaving gaps in understanding for a potentially high-impact operation.

  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 parameters and 100% schema description coverage, the schema fully documents the input structure. The description does not add parameter semantics, but since there are no parameters to explain, a baseline score of 4 is appropriate as no additional information is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.cleanSSHPrivateKey (POST)' is tautological, essentially restating the tool name and title with minimal additional context. It mentions 'settings' and 'POST' but lacks a clear verb and specific resource explanation, failing to distinguish from sibling tools like 'dokploy_settings_saveSSHPrivateKey' or other cleanup tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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. It does not mention prerequisites, timing, or sibling tools like 'dokploy_settings_cleanAll' or 'dokploy_sshKey_remove', leaving the agent without context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanUnusedImagesC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide significant behavioral information: destructiveHint=true indicates this permanently removes data, readOnlyHint=false confirms it's a mutation, idempotentHint=false suggests repeated calls may have different effects, and openWorldHint=true indicates it may affect resources beyond immediate parameters. The description adds no additional behavioral context, but since annotations cover the critical safety profile (destructive nature), the description doesn't need to repeat this. No contradiction exists between description and annotations.

  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 extremely concise - just two lines showing the endpoint and parameter. However, it's under-specified rather than efficiently informative. The structure with 'Parameters:' heading is clear, but the content lacks meaningful information. It's brief but not helpful.

  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 this is a destructive operation (per annotations) with no output schema and minimal parameter documentation, the description is inadequate. It doesn't explain what 'unused images' means, what system this cleans (likely Docker), what the consequences are, whether there's confirmation or dry-run option, or what the response contains. For a destructive tool with open-world implications, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'serverId (string, optional)' as a parameter, but with 0% schema description coverage, the schema only indicates it's a string type. The description provides no semantic meaning - what serverId refers to, what happens if omitted (does it clean images on all servers? default server?), or format requirements. For a single parameter with zero schema documentation, the description adds minimal value beyond stating it's optional.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[settings] settings.cleanUnusedImages (POST)' which is a tautology - it essentially repeats the tool name and adds HTTP method. It mentions 'cleanUnusedImages' which suggests removing unused images, but doesn't specify what type of images (likely Docker images) or what system this operates on. The purpose is somewhat implied but not clearly articulated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 sibling tools list shows other cleanup tools like 'dokploy_settings_cleanAll', 'dokploy_settings_cleanUnusedVolumes', and 'dokploy_settings_cleanDockerPrune', but the description provides no comparison or context for choosing this specific cleanup operation over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getDokployVersionC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering key behavioral traits (safe, non-destructive, repeatable, open-world). The description adds minimal value by implying a GET operation, which aligns with annotations but doesn't provide additional context like rate limits, authentication needs, or return format. With annotations doing the heavy lifting, the description's contribution is limited, warranting a baseline score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description '[settings] settings.getDokployVersion (GET)' is overly concise to the point of under-specification. It lacks a clear, front-loaded purpose statement and consists of fragmented elements that do not form a coherent sentence. While brief, it fails to efficiently convey essential information, making it less helpful than a more structured, albeit longer, description would be.

  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 simplicity (0 parameters, no output schema) and rich annotations, the description is incomplete. It does not explain what the tool returns (e.g., version string, object) or its significance, leaving gaps in understanding despite the annotations covering safety. For a tool that likely returns critical system information, more context on the output and use case is needed to be fully helpful.

  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 0 parameters with 100% schema description coverage, so the input schema fully documents the lack of parameters. The description does not add any parameter information, which is appropriate since there are none. According to the rules, for 0 parameters, the baseline is 4, as no additional parameter semantics are needed beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.getDokployVersion (GET)' is tautological, essentially restating the tool name and title with minimal added context. It mentions 'settings' and 'GET' but lacks a clear, specific verb+resource statement like 'Retrieve the current Dokploy software version' that would distinguish it from sibling tools. This provides minimal differentiation from other settings tools like dokploy_settings_getIp or dokploy_settings_getReleaseTag.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not indicate any specific context, prerequisites, or exclusions for its use. Given the many sibling tools, there is no mention of when this tool is appropriate compared to other version-related or settings tools, leaving the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getIpC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate read-only, non-destructive, idempotent, and open-world behavior, which the description doesn't contradict. However, the description adds minimal value beyond this, as it only hints at a GET operation without detailing output format, error conditions, or rate limits. With annotations covering safety, a baseline score is appropriate, but the description could enhance context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of under-specification. While it uses minimal words, it fails to convey essential information like the resource or purpose, making it inefficient rather than appropriately concise. Every sentence should earn its place, but here the single sentence lacks substance.

  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 simplicity (0 parameters, good annotations), the description is incomplete. It doesn't explain what IP address is retrieved or the return format, and with no output schema, the agent lacks necessary context. For a read-only tool, more detail on the output would improve usability, making this description insufficient.

  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 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add any parameter details, which is acceptable here, but it doesn't compensate for other gaps, so a score of 4 reflects adequacy without extra value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.getIp (GET)' is tautological, essentially restating the tool name and HTTP method without specifying what resource is retrieved. It mentions 'settings' and 'getIp' but doesn't clarify what IP address is being retrieved (e.g., server IP, public IP, network interface IP) or from which context, making the purpose vague and indistinguishable 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.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It lacks any mention of prerequisites, context (e.g., for server configuration, monitoring, or diagnostics), or sibling tools that might serve similar purposes (e.g., dokploy_server_publicIp), leaving the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getOpenApiDocumentC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the bar is lower. The description adds minimal value by indicating this is a GET operation, which aligns with the annotations. However, it doesn't provide any additional behavioral context beyond what the annotations already declare, such as authentication requirements, rate limits, or what specific OpenAPI document is retrieved.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While the description is brief, it's not effectively structured or informative. The bracketed '[settings]' prefix and parenthetical '(GET)' add minimal value without proper context. This isn't true conciseness but rather under-specification - the description fails to convey meaningful information despite its brevity.

  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 that this tool has no output schema, the description should ideally explain what the tool returns. However, it provides no information about the response format, content, or structure of the OpenAPI document. While annotations cover safety aspects, the description fails to address what value this tool provides to the agent, making it incomplete for practical use.

  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 with 100% schema description coverage, so the baseline is 4 even with no parameter information in the description. The description doesn't need to compensate for any parameter documentation gaps since there are no parameters to document.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.getOpenApiDocument (GET)' is tautological, essentially restating the tool name and HTTP method without explaining what it actually does. It doesn't specify what resource is retrieved (OpenAPI document for what system?) or what the output contains. While it mentions 'settings' context, this is vague and doesn't clearly distinguish this tool from other settings-related siblings like dokploy_settings_getWebServerSettings or dokploy_settings_getTraefikPorts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context where this is appropriate, or what other tools might be related. Given the many sibling tools in the settings category, this lack of differentiation is particularly problematic.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getReleaseTagC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds no behavioral context beyond implying a GET operation, which aligns with annotations but doesn't provide additional details like rate limits, authentication needs, or what 'release tag' entails. With annotations doing heavy lifting, the description adds minimal value, warranting a baseline score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of under-specification. It consists of a bracketed category '[settings]' followed by a restatement of the name and HTTP method, which is inefficient and lacks informative content. While brief, it fails to convey meaningful information, making it structurally poor despite its length.

  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 simplicity (0 parameters, no output schema) and rich annotations, the description is incomplete. It doesn't explain what a 'release tag' is, its format, or typical use cases, leaving gaps in understanding despite the annotations covering behavioral safety. For a tool that likely returns version-related data, more context is needed to guide an agent 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the empty schema. A baseline of 4 is appropriate as the description doesn't need to compensate for any gaps, though it also doesn't enhance understanding of inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.getReleaseTag (GET)' is a tautology that restates the name/title with minimal added meaning. It indicates the tool is a GET operation related to settings and release tags, but lacks a specific verb like 'retrieve' or 'fetch' and doesn't clarify what a 'release tag' represents in this context (e.g., version identifier, deployment marker). While it distinguishes from siblings by mentioning 'settings', the purpose remains vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context (e.g., for version checks, deployment tracking), or related tools among the many siblings (e.g., other settings tools like 'getDokployVersion'). Without this, an agent cannot determine appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getUpdateDataC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover read-only, non-destructive, idempotent, and open-world hints, so the agent knows it's a safe, repeatable query. The description adds minimal context with 'POST', but this doesn't contradict annotations—it's a neutral addition. However, it lacks details like rate limits or authentication needs, offering little beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise but under-specified—it's a single bracketed phrase that fails to convey meaningful information. While brief, it lacks structure and front-loaded clarity, making it inefficient rather than helpful.

  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 (implied by 'getUpdateData'), annotations provide safety hints, but there's no output schema. The description is too vague to explain what data is retrieved or its format, leaving significant gaps in understanding the tool's function and output.

  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 parameters and 100% schema description coverage, the schema fully documents the input (none). The description doesn't add parameter details, but since there are no parameters, a baseline of 4 is appropriate—it doesn't need to compensate for gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.getUpdateData (POST)' is tautological—it restates the tool's name and category without explaining what it does. It mentions 'POST' but lacks a clear verb and resource, failing to distinguish its purpose from sibling tools like 'dokploy_settings_getDokployVersion' or 'dokploy_settings_getWebServerSettings'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent with no usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_haveActivateRequestsC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true) already indicate this is a safe, read-only, idempotent operation with open-world semantics. The description adds no behavioral context beyond the implied GET method, such as rate limits, authentication needs, or what 'haveActivateRequests' returns (e.g., a boolean or list). With annotations covering core traits, the description adds minimal value, scoring baseline 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of under-specification. It consists of a single bracketed phrase that fails to convey meaningful information efficiently. While brief, it lacks structure and does not front-load key details, making it ineffective rather than succinct.

  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 simplicity (0 parameters, annotations provided, no output schema), the description is incomplete. It does not explain the return value (e.g., what 'haveActivateRequests' signifies) or usage context, leaving gaps despite the structured data. For a settings-check tool, more semantic detail is needed to guide the 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?

  The input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description does not mention parameters, which is appropriate. Baseline is 4 for zero parameters, as the schema fully handles the lack of inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.haveActivateRequests (GET)' is tautological—it restates the name/title with minimal clarification. It implies a GET operation on a 'haveActivateRequests' setting but lacks a specific verb (e.g., 'check' or 'retrieve') and does not explain what 'haveActivateRequests' means (e.g., whether it indicates pending activation requests). Compared to siblings like 'dokploy_settings_toggleRequests', it fails to distinguish its purpose clearly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., when checking activation requests is needed), or related tools (e.g., 'dokploy_settings_toggleRequests' for toggling requests). This leaves the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_isCloudC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already inform the agent that this is a safe, repeatable read operation. The description adds minimal value by implying a GET request, but it does not disclose any additional behavioral traits such as rate limits, authentication needs, or what specific 'cloud' setting is retrieved. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of being cryptic. It consists of a single phrase '[settings] settings.isCloud (GET)' which is not front-loaded with clear intent and fails to communicate purpose efficiently. While brief, it lacks the structure needed for effective understanding, making it under-specified rather than truly concise.

  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 simplicity (0 parameters, annotations present), the description is incomplete. It does not explain what 'isCloud' means, what value it returns (e.g., boolean, string), or why this information is useful. With no output schema, the description should provide more context about the return value to help the agent understand the tool's role in the system.

  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 0 parameters with 100% schema description coverage, so the input schema fully documents the lack of parameters. The description does not add any parameter information, which is acceptable since there are no parameters to explain. A baseline of 4 is appropriate as the schema handles the parameter semantics completely.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.isCloud (GET)' is vague and tautological. It restates the tool name 'dokploy_settings_isCloud' without clearly explaining what the tool does. While it hints at retrieving a cloud-related setting, it lacks a specific verb and resource definition, failing to distinguish it from sibling tools like 'dokploy_settings_getDokployVersion' or 'dokploy_settings_health'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios. This is particularly problematic given the many sibling tools in the 'settings' category.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_isUserSubscribedC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive safety information (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the agent knows this is a safe, repeatable read operation. The description adds minimal value beyond annotations - the '(GET)' notation reinforces read-only nature but doesn't describe return format, authentication requirements, or rate limits. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While brief, the description is under-specified rather than concise. The single bracketed phrase '[settings] settings.isUserSubscribed (GET)' wastes characters on redundant information (the tool name appears twice) while failing to convey meaningful purpose. Every character should earn its place, but this provides minimal useful information.

  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 simple nature (0 parameters, good annotations), the description is still inadequate. Without an output schema, the description should explain what the tool returns (e.g., boolean subscription status, subscription details object). The current description leaves the agent guessing about the return value format and meaning of 'isUserSubscribed'.

  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 parameters and 100% schema description coverage, the schema fully documents the empty input. The description doesn't need to explain parameters, and it doesn't attempt to. The baseline for 0 parameters is 4, as there's no parameter information to provide beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.isUserSubscribed (GET)' is tautological - it restates the tool name and adds only the HTTP method. It doesn't explain what 'isUserSubscribed' means or what resource it checks. While 'GET' implies retrieval, the purpose remains vague compared to sibling tools like 'dokploy_settings_getCurrentPlan' or 'dokploy_settings_haveActivateRequests' which have clearer purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling settings tools available (e.g., dokploy_settings_getCurrentPlan, dokploy_settings_haveActivateRequests), there's no indication whether this checks subscription status for the current user, all users, or some other scope. No prerequisites, alternatives, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_readMiddlewareTraefikConfigC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true) already indicate this is a safe, non-destructive, idempotent read operation with open-world semantics. The description adds minimal value by implying a read action via 'GET', but it does not disclose additional behavioral traits like rate limits, authentication needs, or what specific data is returned. Since annotations cover the core safety profile, a baseline score of 3 is appropriate, though the description could have provided more context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, cryptic string '[settings] settings.readMiddlewareTraefikConfig (GET)' that is not front-loaded with clear purpose. It lacks proper sentence structure and wastes space on redundant information (e.g., repeating the tool name). While brief, it fails to convey meaningful information efficiently, making it under-specified rather than concise.

  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 (implied by 'middleware Traefik config' in a DevOps context), the description is insufficient. Annotations provide safety hints, but there is no output schema, and the description does not explain what the tool returns (e.g., configuration details, format). Without this, an agent cannot understand the tool's full context or how to interpret results, leaving significant gaps despite the annotations.

  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 input schema has 0 parameters with 100% coverage, meaning no parameters are required or documented. The description does not add parameter information, which is unnecessary here. With zero parameters, the baseline is 4, as there is no need for the description to compensate for missing schema details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.readMiddlewareTraefikConfig (GET)' is tautological—it essentially restates the tool name and adds a method hint. It does not clearly articulate what the tool does (e.g., what middleware Traefik config is, what data it retrieves, or its scope). While it hints at a read operation via 'GET', it lacks a specific verb-resource combination that distinguishes it from siblings like 'dokploy_settings_readTraefikConfig' or 'dokploy_settings_updateMiddlewareTraefikConfig'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it refer to sibling tools (e.g., updateMiddlewareTraefikConfig for modifications). Without such information, an agent cannot determine appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_readTraefikConfigC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide strong behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, indicating a safe, repeatable read operation. The description adds minimal value by specifying 'GET', which aligns with read-only behavior but is redundant given annotations. It does not disclose additional traits like rate limits, authentication needs, or output format, though annotations cover core safety aspects adequately.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of under-specification. While it uses only one short phrase, it fails to convey meaningful information beyond what's in the name/title. It lacks structure and does not front-load critical details, making it inefficient rather than appropriately concise.

  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 (a read operation with no parameters) and rich annotations, the description is incomplete. It does not explain what 'Traefik config' entails, the scope (e.g., global vs. application), or the return format, and there is no output schema. Annotations cover safety, but the description fails to provide necessary context for effective use, especially compared to siblings.

  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 0 parameters, with 100% schema description coverage (empty schema). The description does not discuss parameters, which is appropriate since none exist. It implies no input is needed, aligning with the schema. A baseline of 4 is justified as the description does not need to compensate for any parameter gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.readTraefikConfig (GET)' is tautological, essentially restating the tool name and title with minimal added context. It indicates a GET operation related to Traefik config in settings, but lacks a clear, specific verb-resource statement that distinguishes it from siblings like 'dokploy_settings_updateTraefikConfig' or 'dokploy_application_readTraefikConfig'. The purpose is vague beyond basic HTTP method and resource area.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or exclusions, nor does it reference sibling tools like 'dokploy_settings_updateTraefikConfig' (for updates) or 'dokploy_application_readTraefikConfig' (for application-specific config). Without such guidance, an AI agent cannot determine appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_reloadRedisC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false (indicating mutation), destructiveHint=false (non-destructive), idempotentHint=false (non-idempotent), and openWorldHint=true. The description adds that this is a POST operation, which aligns with the mutation hint. However, it doesn't disclose important behavioral traits beyond what annotations already provide - such as what 'reload' actually does (restarts Redis service? reloads config without restart?), potential side effects, or performance implications. The description neither contradicts annotations nor adds substantial context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise (one bracketed phrase), the description is under-specified rather than efficiently concise. It uses minimal characters but fails to convey essential information. The structure with brackets and parentheses feels like internal API documentation rather than a helpful user-facing description. Every sentence should earn its place, but this single phrase doesn't earn its place by being informative.

  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 this is a mutation tool (readOnlyHint=false) with no output schema, the description is inadequate. It doesn't explain what 'reloadRedis' means operationally, what success/failure looks like, or what the tool returns. With annotations covering basic safety but no output schema, the description should provide more context about the operation's purpose and expected outcomes. Compared to the complexity implied by the tool name and annotations, this description leaves too many questions unanswered.

  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 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters since none exist, and the schema fully documents this. The baseline for 0 parameters is 4, as the description appropriately doesn't waste space on non-existent parameters. The '[settings]' prefix might hint at context but doesn't add meaningful parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.reloadRedis (POST)' is a tautology that restates the name/title with minimal added meaning. It vaguely indicates this is a POST operation for settings related to reloading Redis, but lacks a specific verb-resource statement like 'Reload the Redis configuration in Dokploy settings' that would clarify what the tool actually does. It doesn't distinguish from sibling tools like dokploy_settings_reloadServer or dokploy_settings_reloadTraefik.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or when-not-to-use scenarios. With many sibling tools in the settings category (like dokploy_settings_reloadServer, dokploy_settings_reloadTraefik), there's no indication of how this specific Redis reload differs from other reload operations or when it should be selected.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_reloadServerC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is not read-only, not destructive, not idempotent, and is open-world, but the description adds no behavioral context beyond this. It does not explain what 'reloadServer' entails (e.g., whether it restarts a service, applies configuration changes, or impacts system state), nor does it mention permissions, side effects, or rate limits. However, it does not contradict the annotations, so it avoids a lower score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of being cryptic ('[settings] settings.reloadServer (POST)'), lacking complete sentences or clear structure. It fails to front-load essential information, making it inefficient for quick understanding rather than truly concise.

  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 (a POST operation likely affecting server state), the description is incomplete. It lacks details on what 'reloadServer' means, expected outcomes, or any behavioral nuances, and there is no output schema to compensate. Annotations provide basic hints but do not fully cover the tool's purpose or effects, leaving significant gaps.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description does not add parameter information, but since there are no parameters, a baseline of 4 is appropriate as no compensation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.reloadServer (POST)' is tautological, essentially restating the tool name and title with minimal context. It mentions 'settings' and 'reloadServer' but lacks a clear, specific verb-resource statement explaining what the tool actually does (e.g., reloads server settings, restarts a service, or refreshes configuration). It does not distinguish this from sibling tools like 'dokploy_settings_reloadTraefik' or 'dokploy_settings_updateServer'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it refer to sibling tools (e.g., 'dokploy_settings_reloadTraefik' for Traefik-specific reloads). This leaves the agent without any usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateServerC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=false (mutation), destructiveHint=false (safe), idempotentHint=true (repeatable), openWorldHint=true (flexible). The description adds no behavioral context beyond what annotations already declare. It doesn't explain what 'updateServer' entails, potential side effects, or any constraints. However, it doesn't contradict annotations, so it meets the lowered bar with annotations present but adds no value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[settings] settings.updateServer (POST)'), but this is under-specification rather than effective conciseness. It wastes no words but fails to convey necessary information, making it inefficient for its purpose. A single sentence could have been more informative without losing brevity.

  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 mutation nature (readOnlyHint=false) and lack of output schema, the description is incomplete. It doesn't explain what the tool updates, what the expected outcome is, or any dependencies. Annotations cover safety and idempotency, but the description fails to provide context about the server update operation, leaving the agent with insufficient guidance.

  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 input schema has 0 parameters with 100% description coverage, meaning no parameters are documented because none exist. The description doesn't mention parameters, which is appropriate. Baseline for 0 parameters is 4, as there's nothing to compensate for.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.updateServer (POST)' is tautological, essentially restating the tool name and title with minimal additional context. It mentions 'settings' and 'updateServer' but doesn't specify what aspect of the server is being updated or what the tool actually does beyond the obvious. It fails to distinguish this tool from sibling settings tools like 'dokploy_settings_updateServerIp' or 'dokploy_settings_updateTraefikConfig'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or specific scenarios for invocation. Given the many sibling tools in the 'dokploy_settings_' namespace, this lack of differentiation is a significant gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sshKey_allC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds minimal value beyond this, as it doesn't disclose any behavioral traits like pagination, sorting, filtering, or response format. However, it doesn't contradict the annotations (e.g., it doesn't imply mutation). With annotations covering safety and idempotency, the description's lack of additional context results in a baseline score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description '[sshKey] sshKey.all (GET)' is overly concise to the point of being cryptic. It's front-loaded but lacks meaningful content, failing to convey useful information in its single phrase. While brief, it under-specifies rather than being efficiently informative, making it less helpful for an AI agent.

  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 simplicity (0 parameters, annotations provided), the description is incomplete. It doesn't explain what the tool returns (e.g., a list of SSH keys, their format, or any metadata), and there's no output schema to compensate. For a read operation, the description should at least hint at the return value, but it omits this entirely, leaving gaps in understanding the tool's functionality.

  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 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't add any parameter information, which is acceptable since there are no parameters to document. The baseline for 0 parameters is 4, as the description needn't compensate for missing schema details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[sshKey] sshKey.all (GET)' is tautological, essentially restating the tool name and HTTP method without clarifying what the tool actually does. It mentions 'sshKey' and 'all' but doesn't specify the action (e.g., list, retrieve, fetch) or what resource is being accessed. Compared to sibling tools like 'dokploy_sshKey_create' or 'dokploy_sshKey_remove', it fails to distinguish its specific purpose 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or relationships with sibling tools (e.g., 'dokploy_sshKey_one' for a single SSH key or 'dokploy_sshKey_create' for creating new ones). There's no indication of when this tool is appropriate or what scenarios it addresses.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sso_listProvidersC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a read-only, non-destructive, idempotent, and open-world operation. The description adds minimal value by specifying the HTTP method (GET), which aligns with read-only behavior, but doesn't disclose additional behavioral traits like response format, pagination, or authentication requirements. Since annotations cover the core safety profile, the description's contribution is limited but not contradictory.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[sso] sso.listProviders (GET)'), but this brevity stems from under-specification rather than efficient communication. It fails to convey essential information about the tool's purpose and usage, making it ineffective despite its short length. It's not front-loaded with useful context.

  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 simplicity (no parameters, good annotations), the description is incomplete. It lacks details on what 'listProviders' returns (e.g., provider names, configurations, statuses), and there's no output schema to compensate. For a list operation, the description should clarify the scope and format of the returned data, which it doesn't.

  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 schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion. A baseline of 4 is appropriate as the description doesn't detract from the well-documented absence of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[sso] sso.listProviders (GET)' is tautological—it essentially restates the tool name with added HTTP method and namespace. It doesn't clearly articulate what the tool does beyond implying it lists something related to SSO providers. It fails to specify what 'listProviders' means in this context (e.g., listing available SSO providers, their configurations, or types).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include dokploy_sso_one (likely to get a single provider) and dokploy_sso_deleteProvider, there's clear potential for confusion, but the description offers no differentiation. It lacks any context about prerequisites, typical use cases, or comparisons to related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sso_removeTrustedOriginC
  2.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide critical behavioral hints (destructiveHint: true, readOnlyHint: false, idempotentHint: false, openWorldHint: true). The description doesn't contradict these, but it adds minimal value beyond them—only the HTTP method (POST). It doesn't explain what 'destructive' means here (e.g., whether removal is permanent, affects authentication, or has side effects), leaving some behavioral context uncovered.

  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 brief but not effectively structured. It includes extraneous details like '[sso]' and '(POST)' that don't add clarity, while missing essential explanatory content. It's concise but under-specified, failing to use its limited space to convey purpose or usage.

  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 a destructive tool with no output schema and 0% schema description coverage, the description is inadequate. It lacks details on what the tool does, when to use it, parameter semantics, or expected outcomes. Annotations help, but the description doesn't fill gaps in understanding the operation's impact or context within the SSO system.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists the parameter name ('origin') with type and requirement, repeating schema info without adding meaning. It doesn't explain what an 'origin' is (e.g., a URL, domain, or identifier), its format, or examples, leaving the parameter poorly understood despite the schema's structural details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('sso.removeTrustedOrigin') and adds minimal context ('[sso]' prefix and 'POST' method), but it doesn't clearly articulate what the tool actually does. It doesn't specify what a 'trusted origin' is in this context, what effect removal has, or what resource is being modified. This is borderline tautological with 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'dokploy_sso_addTrustedOrigin' or 'dokploy_sso_getTrustedOrigins', nor does it indicate prerequisites, typical use cases, or when this operation is appropriate versus other SSO management tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sso_showSignInWithSSOC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description's burden is reduced. The description adds minimal value by indicating it's a GET operation, which aligns with the read-only nature. However, it doesn't provide any additional behavioral context about what 'show' means operationally, what gets displayed, or any constraints beyond what annotations already cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise, the description is under-specified rather than efficiently informative. The single bracketed phrase '[sso] sso.showSignInWithSSO (GET)' wastes space on redundant information (repeating the tool name) while failing to convey meaningful purpose or usage. It's not appropriately sized for a tool that presumably has some functional significance in the SSO context.

  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 the SSO domain and the extensive sibling tool list, this description is woefully incomplete. There's no output schema, and the description provides no information about what this tool returns or how it differs from other SSO tools. The annotations provide safety information, but the functional purpose remains unclear, making it difficult for an agent to understand when and why to invoke this specific tool.

  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 schema description coverage is 100% (empty schema). With no parameters to document, the baseline score is 4. The description doesn't need to compensate for any parameter documentation gaps since there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[sso] sso.showSignInWithSSO (GET)' is essentially a tautology that restates the tool name with minimal additional context. It indicates the tool is related to SSO and uses GET method, but doesn't specify what it actually does (e.g., displays SSO sign-in options, retrieves SSO configuration, or shows available providers). The description fails to distinguish this tool from sibling SSO tools like dokploy_sso_listProviders or dokploy_sso_one.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or relationships to other SSO tools in the extensive sibling list. An agent would have no idea whether to use this tool versus dokploy_sso_listProviders or dokploy_sso_getTrustedOrigins for SSO-related tasks.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_stripe_canCreateMoreServersC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover key behavioral traits (read-only, non-destructive, idempotent, open-world), so the bar is lower. The description adds minimal context with 'stripe' and 'GET', but doesn't disclose additional behaviors like what 'canCreateMoreServers' returns (e.g., boolean, quota details), error conditions, or Stripe-specific requirements. It doesn't contradict annotations, but adds little beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise but under-specified, not efficient. It's a single bracketed phrase that fails to convey purpose or usage, wasting space on redundant information (name and HTTP method). While brief, it lacks structure and front-loaded clarity, making it unhelpful rather than succinct.

  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 (likely checking server creation limits via Stripe), the description is incomplete. Annotations provide safety hints, but without an output schema, the description should explain the return value (e.g., boolean, quota object). It fails to do so, leaving the agent unsure of what to expect, which is inadequate for a tool that may inform critical decisions.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't add parameter semantics, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for. No value is added, but none is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[stripe] stripe.canCreateMoreServers (GET)' restates the tool name and adds only the HTTP method and a vague 'stripe' context. It lacks a specific verb and resource definition, failing to explain what 'canCreateMoreServers' actually checks (e.g., quota, billing status, or capacity). While it hints at a Stripe-related check, it's tautological and doesn't differentiate from siblings like 'dokploy_stripe_getCurrentPlan' or 'dokploy_stripe_getProducts'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions. Given siblings like 'dokploy_stripe_getCurrentPlan' and 'dokploy_stripe_upgradeSubscription', an agent would not know if this tool is for pre-checking server creation limits, verifying subscription tiers, or something else, leading to potential misuse.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_stripe_getCurrentPlanC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation. The description adds that it's a 'GET' method, which aligns with read-only behavior and doesn't contradict annotations. However, it doesn't disclose additional behavioral traits like authentication requirements, rate limits, or what 'current plan' refers to in context. With annotations covering safety, the description adds minimal value beyond method type.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[stripe] stripe.getCurrentPlan (GET)'), but this brevity stems from under-specification rather than efficient communication. It lacks essential details about purpose and usage, making it ineffective despite its short length. Every sentence should earn its place, but here the single fragment fails to provide adequate information.

  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 (likely retrieving subscription data) and lack of output schema, the description is incomplete. Annotations cover safety, but the description doesn't explain what 'current plan' means, what data is returned, or any prerequisites. For a tool that might involve billing or subscription details, more context is needed to guide the agent 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 input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't mention parameters, which is appropriate. Baseline is 4 for zero parameters, as there's nothing to compensate for and the description doesn't mislead about inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[stripe] stripe.getCurrentPlan (GET)' restates the tool name and adds minimal context. It indicates the tool is related to Stripe and uses HTTP GET, but doesn't specify what 'getCurrentPlan' actually retrieves (e.g., current subscription plan details for a user/organization). This is a tautology with slight elaboration, falling short of clearly stating the specific action and resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include other Stripe-related tools like 'dokploy_stripe_getInvoices' and 'dokploy_stripe_getProducts', there's no indication of when this tool is appropriate or what distinguishes it from those siblings. This leaves the agent without contextual usage information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_stripe_getProductsC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal value by implying a read operation via 'GET', but does not disclose additional behavioral traits like rate limits, authentication needs, or response format, which are relevant for a Stripe integration.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of being underspecified—it consists of a single bracketed phrase without meaningful structure. While brief, it fails to convey essential information, making it inefficient rather than appropriately concise.

  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 (integrating with Stripe) and the absence of an output schema, the description is incomplete. It does not explain what the tool returns (e.g., a list of products) or any Stripe-specific nuances, leaving gaps despite the comprehensive annotations.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the absence of parameters, aligning with the baseline for zero parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[stripe] stripe.getProducts (GET)' is tautological—it essentially restates the tool name and adds the HTTP method, which is redundant. It does not clearly articulate what the tool does (e.g., retrieve product listings from Stripe) or differentiate it from sibling tools like 'dokploy_stripe_getInvoices', leaving the purpose vague.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 lacks context, prerequisites, or any mention of related tools (e.g., for creating or updating products), providing no usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_allC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover the basic safety profile. The description adds minimal value by indicating it's a GET operation, but doesn't disclose important behavioral traits like pagination, rate limits, authentication requirements, or what 'all' actually means in terms of scope. With annotations doing the heavy lifting, a baseline 3 is appropriate, though the description could add more context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise with just 4 words, the description is under-specified rather than efficiently informative. It wastes space on redundant information (the tool name is already 'dokploy_user_all') and doesn't front-load useful information. The bracketed '[user]' prefix adds no value. This isn't effective conciseness - it's inadequate specification.

  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 simplicity (0 parameters, good annotations) but lack of output schema, the description should at least indicate what the tool returns. Without an output schema, the agent doesn't know if this returns user objects, IDs, or some other format. The description fails to provide this basic contextual information, making it incomplete for proper tool invocation despite the simple parameter situation.

  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 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters, and the baseline for 0 parameters is 4. No parameter information is missing or needed beyond what's already covered by the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.all (GET)' is tautological - it essentially restates the tool name and adds the HTTP method. It doesn't explain what the tool actually does (retrieve all users), nor does it distinguish this from sibling tools like 'dokploy_user_one' or 'dokploy_user_get'. The purpose remains vague beyond the literal interpretation of 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 Guidelines1/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. With many sibling tools in the user domain (dokploy_user_one, dokploy_user_get, dokploy_user_update, etc.), the description provides no context about when this specific 'all' endpoint should be used versus other user-related tools. No prerequisites, limitations, or alternatives are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_generateTokenC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide basic safety information (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), but the description adds no behavioral context beyond what's in the annotations. It doesn't explain what the generated token is for, whether it requires authentication, what permissions it grants, or how it should be used. However, since annotations cover the basic safety profile, this meets the lower bar for tools with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise (one short phrase), the description is under-specified rather than efficiently informative. It wastes its limited space on redundant information (repeating the tool name) rather than providing useful context. A truly concise description would use its few words to convey actual meaning about the tool's purpose.

  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?

  For a token generation tool with no output schema, the description is severely inadequate. It doesn't explain what the token is for (API access? session? metrics?), what format it returns, whether it's a JWT or other type, or how it should be used. The annotations provide basic safety info, but the description fails to give the agent enough context to understand when and how to invoke this tool 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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of parameters. The description doesn't need to explain parameters, and the baseline for 0-parameter tools with full schema coverage is 4. The description doesn't contradict or add to the parameter information, which is appropriate given the empty parameter set.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.generateToken (POST)' is tautological - it restates the tool name and adds HTTP method without explaining what the tool actually does. It doesn't specify what kind of token is generated, for what purpose, or what resource it operates on. While 'generateToken' suggests creating an authentication token, the description fails to provide meaningful context about the operation's purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. There are many sibling tools related to user management (dokploy_user_createApiKey, dokploy_user_session, dokploy_user_getMetricsToken, etc.), but no indication of when this specific token generation tool is appropriate versus those other authentication/authorization tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_getC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description's burden is lower. However, it adds no context beyond what annotations already cover—no information about authentication requirements, rate limits, or what specific user data is returned. The description doesn't contradict annotations, but it adds no value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While brief, the description is under-specified rather than concise. The single phrase '[user] user.get (GET)' fails to convey meaningful information—it's essentially a label, not a helpful description. Every sentence should earn its place, but this provides almost no value.

  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 simplicity (0 parameters, good annotations), the description is incomplete. It doesn't explain what user data is retrieved, whether it's the current user or a specific one, or what the output looks like (no output schema exists). For a user-related tool in a system with many alternatives, this leaves significant gaps in understanding its role.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to compensate for any parameter gaps, and it correctly implies no parameters are needed (though this is inferred from the name/context rather than explicitly stated). Baseline for 0 parameters is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.get (GET)' is tautological, essentially restating the tool name and HTTP method without specifying what it actually does. It doesn't clarify what 'user.get' retrieves (current user info, user by ID, etc.) or distinguish it from sibling tools like dokploy_user_one or dokploy_user_all.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. Given sibling tools like dokploy_user_one, dokploy_user_all, and dokploy_user_session, the description offers no indication of when this specific 'get' operation is appropriate or what distinguishes it from other user-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_getInvitationsC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the agent knows it's a safe, repeatable read operation. The description adds minimal behavioral context—it implies a GET request but doesn't detail response format, pagination, or error conditions. With annotations doing heavy lifting, the description adds little extra value, warranting a baseline score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of under-specification—it's a single cryptic phrase that fails to convey purpose. While brief, it lacks meaningful structure or front-loaded clarity. Every sentence should earn its place, but this one provides little value beyond noise.

  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 zero parameters and rich annotations, the description is incomplete. It doesn't explain what 'invitations' are, the return format, or how it differs from sibling tools. With no output schema, the description should clarify expected results (e.g., list of invitation objects). It leaves too much undefined for effective agent use.

  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?

  There are zero parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here. Baseline is 4 for zero-param tools, as there's nothing to compensate for.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.getInvitations (GET)' is tautological—it restates the tool name and adds HTTP method, but lacks a clear verb and resource specification. It doesn't explain what 'getInvitations' actually does (e.g., retrieve pending invitations for the current user). Compared to siblings like 'dokploy_user_sendInvitation' or 'dokploy_organization_allInvitations', it fails to differentiate its scope or purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user authentication), context (e.g., personal vs organizational invitations), or refer to related tools like 'dokploy_organization_allInvitations' for broader access. The description offers no usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_getMetricsTokenC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the core safety profile. The description adds minimal value by implying this is a GET operation (which aligns with annotations) but doesn't disclose any additional behavioral traits like authentication requirements, rate limits, or what the token is used for. With comprehensive annotations, the bar is lower, but the description could still add more context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While brief, the description '[user] user.getMetricsToken (GET)' is under-specified rather than concise. It wastes characters on redundant information (the tool name) without adding meaningful content. Every sentence should earn its place, but this single fragment fails to provide adequate information despite its brevity.

  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 apparent purpose (retrieving/generating a metrics token for monitoring), the description is incomplete. With no output schema and minimal annotations, the description should explain what the token is used for, its format, or how it relates to other metrics tools. Compared to siblings like 'dokploy_user_getServerMetrics', this leaves significant gaps in understanding the tool's role.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate since there are no parameters to explain beyond what the structured schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.getMetricsToken (GET)' is a tautology that restates the tool name and adds minimal context. It mentions 'user' and 'GET' but doesn't specify what the tool actually does - whether it retrieves, generates, or validates a metrics token. Compared to sibling tools like 'dokploy_user_getPermissions' or 'dokploy_user_generateToken', it fails to distinguish its specific purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or relationship to sibling tools like 'dokploy_user_getServerMetrics' or 'dokploy_settings_getServerMetrics'. The agent receives zero usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_getPermissionsC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover key behavioral traits (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description's burden is lower. The description adds minimal value by implying a GET operation, but doesn't disclose additional context like authentication needs, rate limits, or what 'permissions' entail. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of under-specification—it's a single bracketed phrase with no complete sentences. While brief, it fails to convey meaningful information efficiently, as it doesn't earn its place with useful content.

  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 simplicity (0 parameters, good annotations) but lack of output schema, the description is incomplete. It doesn't explain what 'permissions' are returned, the format, or any error conditions. For a user-facing tool in a complex system, more context is needed despite the annotations.

  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 parameters and 100% schema description coverage, the baseline is high. The description doesn't add parameter details (since there are none), but it implicitly suggests no inputs are required. This is adequate given the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.getPermissions (GET)' is tautological—it restates the tool name with minor formatting and adds the HTTP method, but doesn't explain what the tool actually does. It lacks a clear verb+resource statement (e.g., 'Retrieve permissions for the current user') and doesn't differentiate from sibling tools like dokploy_user_get or dokploy_user_all.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or exclusions. Sibling tools like dokploy_user_getPermissions (if any) or related permission tools aren't referenced, leaving the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_getServerMetricsC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the agent knows it's a safe, repeatable read operation. The description adds no behavioral context beyond the HTTP method, such as rate limits, authentication needs, or what metrics are returned. It doesn't contradict annotations, but adds minimal value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is under-specified, not concise—it's a single cryptic string "[user] user.getServerMetrics (GET)" that fails to communicate purpose or usage. While brief, it wastes its limited space on redundant details rather than helpful information, lacking front-loaded clarity.

  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 likely complexity (retrieving server metrics), the description is incomplete. Annotations provide safety, but no output schema exists, and the description doesn't explain return values (e.g., metric types, format). It fails to add meaningful context beyond structured fields, leaving gaps for the 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?

  There are 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter information, which is unnecessary here. Baseline is 4 for zero parameters, as no compensation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description "[user] user.getServerMetrics (GET)" is tautological—it restates the name and adds HTTP method without explaining what the tool does. It doesn't specify what server metrics are retrieved (e.g., CPU, memory, disk usage) or for which server, making the purpose vague and indistinguishable from siblings like 'dokploy_server_getServerMetrics'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., server access), context (e.g., monitoring needs), or sibling tools like 'dokploy_server_getServerMetrics' or 'dokploy_user_getContainerMetrics', leaving the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_sessionC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, indicating a safe, non-destructive, repeatable operation with open-world semantics. The description adds minimal context by specifying 'GET', which aligns with read-only behavior, but does not disclose additional traits like authentication requirements, rate limits, or what data is returned. Since annotations cover the safety profile adequately, the description's limited addition warrants a baseline score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description '[user] user.session (GET)' is overly concise to the point of under-specification. It consists of a single phrase that fails to convey meaningful information beyond the tool name and HTTP method. While brief, it does not effectively communicate purpose or usage, making it inefficient rather than appropriately concise.

  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 simplicity (0 parameters, annotations provided, no output schema), the description is incomplete. It lacks details on what the tool returns (e.g., session data, user info) and any contextual nuances like authentication needs. While annotations cover safety, the description should add more about the operation's outcome to be fully helpful for an 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?

  The input schema has 0 parameters with 100% description coverage, meaning no parameters need documentation. The description does not add parameter information, which is acceptable given the lack of parameters. It implies a simple, parameterless operation, aligning with the schema, so it meets the baseline for this scenario.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.session (GET)' is tautological, essentially restating the tool name and title with minimal additional information. It indicates a GET operation on a user session resource but lacks specificity about what the tool actually does (e.g., retrieves current session details, validates authentication). It does not differentiate from sibling tools like dokploy_user_get or dokploy_user_one, which also handle user-related operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as whether it's for authenticated users only or how it differs from other user-related tools in the sibling list (e.g., dokploy_user_get). This absence of usage instructions leaves the agent without direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_whitelabeling_getC
  2.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no additional behavioral context beyond what these annotations convey. It doesn't describe authentication requirements, rate limits, error conditions, or what specific whitelabeling data is returned. However, it doesn't contradict the annotations (it mentions 'GET' which aligns with read-only), so it meets the lower bar set by having annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise ('[whitelabeling] whitelabeling.get (GET)') but this brevity comes at the cost of being under-specified rather than efficient. It uses brackets and parentheses in a way that doesn't add clarity, and the single line fails to communicate meaningful information. While it's short, it doesn't effectively use its limited space to help an AI agent understand the tool's purpose.

  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 (whitelabeling operations can involve multiple settings), the absence of an output schema, and rich annotations, the description is inadequate. It doesn't explain what whitelabeling data is retrieved, the format of the response, or how this differs from the 'getPublic' sibling. While annotations cover safety aspects, the description fails to provide necessary context about the domain-specific operation, leaving significant gaps for an agent to understand what this tool actually does.

  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 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters since none exist. It appropriately doesn't waste space discussing non-existent inputs, though it could have mentioned that no parameters are required. Given the baseline for 0 parameters is 4, this score reflects that the description doesn't add parameter semantics but doesn't need to.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[whitelabeling] whitelabeling.get (GET)' is essentially a tautology that restates the tool name and adds the HTTP method. It doesn't specify what 'get' means in this context (retrieve whitelabeling settings, configuration, or status) or what resource it operates on. While it includes 'whitelabeling' which gives some domain context, it lacks a clear verb+resource statement that distinguishes its purpose from siblings like 'dokploy_whitelabeling_getPublic' or 'dokploy_whitelabeling_update'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool should be used instead of 'dokploy_whitelabeling_getPublic' (which likely retrieves public-facing whitelabeling data) or 'dokploy_whitelabeling_update' (which modifies whitelabeling settings). There's no context about prerequisites, access levels, or typical use cases for this specific get operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_ai_suggestC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide structured information (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), which the description doesn't contradict. However, the description adds minimal behavioral context beyond what annotations already declare. It doesn't explain what kind of suggestions are generated, whether there are rate limits, authentication requirements, or what the typical response format looks like. With annotations covering the basic safety profile, the description adds some value by indicating it's a POST operation but lacks rich behavioral details.

  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 extremely concise with just the operation type and parameter listing. While it could be more informative, every element serves a purpose - it identifies the HTTP method and lists the parameters. There's no wasted text, though the structure is minimal rather than optimally informative.

  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 an AI suggestion tool with 3 parameters, 0% schema description coverage, no output schema, and no behavioral context beyond basic annotations, the description is inadequate. It doesn't explain what the tool returns, what kind of suggestions it generates, or how the parameters interact. For a tool that likely involves AI model interaction, this leaves significant gaps in understanding how to use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the parameters have descriptions in the schema. The tool description only lists parameter names and types (aiId, input, serverId) without explaining what these parameters represent, what format they should be in, or what values are expected. For a tool with 3 parameters and 0% schema coverage, the description fails to compensate by providing meaningful semantic information about what each parameter does.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name 'ai_suggest' as 'ai.suggest' with minimal additional information. It doesn't specify what kind of suggestions are generated, for what purpose, or what resource is being acted upon. While it mentions it's a POST operation, this doesn't meaningfully clarify the tool's purpose 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?

  The description provides no guidance on when to use this tool versus alternatives. With many sibling AI tools available (dokploy_ai_create, dokploy_ai_get, dokploy_ai_getAll, dokploy_ai_getModels, dokploy_ai_one, dokploy_ai_update, dokploy_ai_delete, dokploy_ai_deploy), there's no indication of when 'suggest' is appropriate versus other AI operations. No context, prerequisites, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_auditLog_allC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating it's a safe, repeatable read operation with open-world semantics. The description adds no behavioral context beyond this (e.g., pagination details, rate limits, or auth requirements), but it doesn't contradict annotations, so it meets the lower bar with annotations present.

  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 structured with a header and bullet-pointed parameters, making it easy to scan. It's appropriately sized without unnecessary fluff, though the header is redundant with the name/title.

  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 9 parameters, 0% schema coverage, no output schema, and annotations covering safety, the description is incomplete. It lists parameters but doesn't explain their semantics, return values, or behavioral nuances like pagination (implied by limit/offset), leaving gaps for effective tool use.

  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 0%, but the description lists all parameters with types and enums, adding meaning beyond the bare schema (e.g., clarifying optional enums for action and resourceType). However, it doesn't explain parameter purposes (e.g., what 'from' and 'to' represent) or usage, so it partially compensates for the low coverage but not fully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description merely restates the tool name and HTTP method ('[auditLog] auditLog.all (GET)'), which is tautological. It doesn't specify what the tool actually does (e.g., retrieve audit logs with filtering capabilities) or distinguish it from siblings like other audit-related tools (none listed, but it doesn't clarify 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 Guidelines1/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 lacks context about prerequisites, typical use cases, or any mention of sibling tools (e.g., if there are other audit log tools for specific scenarios).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_createC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these annotations but adds minimal behavioral context beyond the parameter list. It doesn't explain what 'create' entails (e.g., whether it triggers an immediate backup, schedules it, or requires specific permissions), leaving gaps despite the annotations covering basic safety.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured as a parameter list without a clear introductory sentence explaining the tool's purpose. It's front-loaded with '[backup] backup.create (POST)' but then devolves into a bare list, lacking efficient communication. The parameter enumeration is redundant with the schema and doesn't add value, making it verbose yet under-informative.

  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 (16 parameters, creation operation), lack of output schema, and minimal annotations, the description is incomplete. It doesn't explain the tool's behavior, expected inputs, or outcomes, leaving significant gaps for an AI agent to understand how to invoke it correctly. The parameter list alone is insufficient for a tool of this nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 16 parameters (5 required), the description lists parameters but provides no semantic explanation. It doesn't clarify what values are expected (e.g., format for 'schedule', meaning of 'prefix', how 'database' relates to 'databaseType'), failing to compensate for the lack of schema descriptions and leaving parameters largely ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'backup.create (POST)' which indicates it creates backups, but it's vague about what exactly is being backed up. It mentions parameters like database, databaseType, and composeId, suggesting it can back up databases or compose services, but doesn't clearly articulate the tool's scope or differentiate it from sibling backup tools like manual backup tools for specific database types.

  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 is provided on when to use this tool versus alternatives. The description lists parameters but doesn't indicate prerequisites, when this scheduled backup creation is appropriate compared to manual backups, or how it relates to other backup tools in the sibling list (e.g., dokploy_backup_manualBackupPostgres).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_manualBackupMongoC
  2.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is not read-only, destructive, or idempotent, and it's open-world, but the description adds minimal behavioral context. It mentions 'POST' method, implying a write operation, but does not disclose details like what the backup entails, potential impacts, or any rate limits. With annotations covering basic hints, the description adds little value beyond the method.

  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 brief and front-loaded with the tool name and method, but includes redundant formatting like brackets and parentheses. It efficiently conveys the core action in one line, though it could be more polished by removing extraneous characters.

  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 involves a write operation (POST) with no output schema and low schema coverage, the description is incomplete. It lacks details on what the backup does, expected outcomes, error conditions, or how it fits into the backup workflow, making it inadequate for informed use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'backupId' as a required string parameter without explaining its meaning, format, or how to obtain it. This fails to compensate for the lack of schema descriptions, leaving the parameter's semantics unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool performs a manual backup for MongoDB ('backup.manualBackupMongo'), which clarifies the verb (backup) and resource (MongoDB). However, it does not differentiate from sibling backup tools like 'manualBackupPostgres' or 'manualBackupMariadb' beyond the resource name, leaving the purpose somewhat vague in distinguishing specific use cases.

  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 is provided on when to use this tool versus alternatives. The description lacks context such as prerequisites, timing, or comparisons to other backup tools in the sibling list, leaving the agent without clear usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_bitbucket_testConnectionC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these but adds minimal behavioral context—it implies a POST request to test connectivity. However, it lacks details on what the test involves (e.g., network check, auth validation), expected outcomes, or error handling, leaving gaps despite annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is poorly structured: it starts with a redundant line '[bitbucket] bitbucket.testConnection (POST)' and then lists parameters without explanation. This format is inefficient and not front-loaded with useful information. While concise in length, it wastes space on unhelpful repetition rather than providing clear guidance.

  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 (6 parameters, 0% schema coverage, no output schema), the description is inadequate. It doesn't explain what the tool returns (e.g., success/failure status, error messages) or how parameters interact. With annotations providing some safety context but no output schema, the description fails to complete the picture for effective agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters but provides no semantic meaning—e.g., what 'bitbucketId' represents, how 'apiToken' differs from 'appPassword', or when optional fields are needed. This leaves parameters largely unexplained, failing to add value beyond the schema's structural information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool is for testing a Bitbucket connection, which is a specific purpose. However, it doesn't clearly distinguish this from sibling tools like 'dokploy_bitbucket_create' or 'dokploy_bitbucket_update', nor does it specify what 'testConnection' entails beyond the name. The description is essentially a restatement of the tool name with parameter listing.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical use cases (e.g., after configuring Bitbucket credentials), or what constitutes a successful test. Without this context, the agent must infer usage from the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_clearDeploymentsC
  2.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate it's not read-only, not destructive, not idempotent, and open-world. The description adds no behavioral context beyond the parameter, such as what 'clear' entails (e.g., deletion, archiving), permissions needed, or side effects. With annotations present but minimal description, it fails to add meaningful value.

  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 brief and front-loaded with the tool name and HTTP method, but it wastes space on redundant formatting (brackets, parentheses) and lacks efficient information delivery. It's concise but under-specified, not optimally structured.

  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 1 parameter with 0% schema coverage, no output schema, and annotations that don't fully explain behavior, the description is incomplete. It doesn't clarify what 'clearDeployments' does, its outcomes, or error conditions, making it inadequate for safe use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'composeId' as a required string without explaining its format, source, or purpose. No additional meaning is provided beyond the schema, leaving the parameter poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool clears deployments for a compose, which is a specific verb+resource. However, it doesn't distinguish from sibling tools like 'dokploy_application_clearDeployments' or 'dokploy_compose_cleanQueues', leaving the scope unclear. The purpose is identifiable but lacks differentiation.

  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 versus alternatives is provided. The description only lists the parameter without context, prerequisites, or exclusions. This leaves the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_deployC
  2.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide hints (non-readOnly, non-destructive, non-idempotent, openWorld), but the description adds minimal behavioral context. It mentions 'POST' which implies a write operation, aligning with annotations, but doesn't disclose what 'deploy' does (e.g., triggers a build, restarts services, may have side effects like downtime). For a deployment tool with no output schema, more detail on behavior (e.g., asynchronous, returns deployment ID) would help.

  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 brief but not optimally structured. It front-loads '[compose] compose.deploy (POST)', which is useful, but the parameter list is redundant with the schema and lacks explanatory value. The two sentences are efficient but could be more informative by replacing the parameter list with usage context.

  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 (deployment operation with 3 parameters), lack of output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what happens during deployment, what the output might be (e.g., success status, deployment logs), or error conditions. With annotations covering basic hints, more operational context is needed for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (composeId, title, description) but doesn't explain their meaning (e.g., composeId identifies which compose to deploy, title/description are optional metadata for the deployment). Without this, the agent cannot understand what values to provide beyond basic types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool is for 'compose.deploy (POST)', which implies deploying a compose configuration. However, it's vague about what 'compose' refers to (likely Docker Compose) and doesn't specify what deployment entails (e.g., starting containers, updating services). It distinguishes from siblings like 'dokploy_compose_create' or 'dokploy_compose_update' by focusing on deployment, but lacks specificity about the resource being deployed.

  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 is provided on when to use this tool versus alternatives. With many sibling tools (e.g., 'dokploy_compose_create', 'dokploy_compose_redeploy', 'dokploy_compose_start'), the description doesn't indicate prerequisites (e.g., requires an existing compose), exclusions, or typical scenarios. The agent must infer usage from the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_getDefaultCommandC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the bar is lower. The description adds minimal value by indicating it's a GET operation, which aligns with the read-only annotation. However, it doesn't provide any additional behavioral context beyond what annotations already cover - no information about rate limits, authentication needs, error conditions, or what 'default command' actually means in practice.

  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 extremely concise - just two lines that show the tool context, name, HTTP method, and parameter. There's no wasted text or redundancy. However, the structure could be improved by front-loading the purpose rather than starting with bracketed context. It's efficient but could be more purpose-driven in its organization.

  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 this is a read operation (per annotations) with no output schema, the description should explain what the tool returns. It doesn't describe the return value format, what a 'default command' looks like, or any error scenarios. With 0% schema description coverage and no output schema, the description fails to compensate for these gaps. For a tool that presumably returns some command string or configuration, this is inadequate.

  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 description mentions 'Parameters: - composeId (string, required)' which exactly mirrors the input schema. With 0% schema description coverage, the schema provides no parameter descriptions, so the description at least identifies the parameter. However, it doesn't add any semantic meaning - it doesn't explain what composeId represents, what format it should be in, where to find it, or what happens if an invalid ID is provided. The baseline is 3 because the description acknowledges the parameter exists but doesn't add meaningful context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[compose] compose.getDefaultCommand (GET)' which is tautological - it essentially repeats the tool name and adds the HTTP method. It doesn't explain what a 'default command' is, what resource it retrieves it from, or what the command is used for. While it mentions 'compose' context, it doesn't specify what this default command represents (e.g., Docker Compose command, deployment command, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, when this tool is appropriate, or what other tools might be related. Given the many sibling tools in the Dokploy system (including other compose_* tools), this lack of contextual guidance is a significant gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_customRole_allC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true) already indicate this is a safe, read-only, idempotent operation that may return partial results. The description adds minimal value by including '(GET)', which aligns with read-only behavior but doesn't contradict annotations. However, it lacks additional context such as rate limits, authentication needs, or what 'all' entails (e.g., pagination, filtering).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is overly concise to the point of being cryptic. It consists of a single fragment '[customRole] customRole.all (GET)' that lacks complete sentences or clear structure. While brevity is good, this under-specifies the tool's purpose and fails to communicate effectively, making it inefficient for an agent's understanding.

  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 has 0 parameters, rich annotations, and no output schema, the description is minimally adequate but incomplete. It doesn't explain what 'all' returns (e.g., a list of custom roles) or any behavioral nuances, leaving gaps in understanding despite the annotations covering safety and idempotency. For a read operation, more detail on the return value would be helpful.

  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 input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description doesn't add any parameter information, which is acceptable since there are no parameters to describe. A baseline of 4 is appropriate as the schema fully covers the absence of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[customRole] customRole.all (GET)' is a tautology that restates the name and title without clarifying what the tool does. It mentions 'customRole' and 'all' but doesn't specify the action (e.g., list, retrieve) or the resource scope, making it vague. While it includes '(GET)' which hints at a read operation, it fails to provide a clear, specific purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or sibling tools (e.g., dokploy_customRole_create, dokploy_customRole_update) that might be relevant for different operations. This leaves the agent with no information to make an informed selection among related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_environment_byProjectIdC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which already inform the agent this is a safe, repeatable read operation. The description adds minimal value by specifying 'GET' and listing the parameter, but doesn't disclose any additional behavioral traits like what 'environment' entails, potential rate limits, authentication needs, or return format. Since annotations cover the safety profile adequately, a baseline score of 3 is appropriate.

  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 brief and front-loaded with the tool name and HTTP method, followed by a parameter list. It avoids unnecessary verbosity, but the structure could be improved by using complete sentences or clearer formatting. Despite this, it efficiently conveys basic information without waste.

  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 has no output schema and annotations cover safety aspects, the description is incomplete for effective use. It lacks details on what 'environment' means, the return format, error conditions, or how it differs from other environment tools. For a read operation with one parameter but unclear semantics, more context is needed to guide the agent adequately.

  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 0%, meaning the parameter 'projectId' has no description in the schema. The tool description lists 'projectId (string, required)' but provides no additional semantic context—such as what a projectId is, where to find it, format examples, or valid values. With only one parameter and no schema description, the description partially compensates by stating it's required, but fails to add meaningful clarification beyond what's inferred from the schema structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[environment] environment.byProjectId (GET)' which is essentially a tautology of the tool name/title. It doesn't specify what 'environment' refers to in this context (e.g., deployment environment, configuration environment) or what the tool actually retrieves. While it mentions 'GET' and includes a parameter, the purpose remains vague and doesn't distinguish this from sibling environment tools like dokploy_environment_one or dokploy_environment_search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for projectId usage, or differentiate it from other environment-related tools in the sibling list. Without this information, an agent cannot make informed decisions about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitea_testConnectionC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description doesn't add any behavioral context beyond these annotations—it doesn't explain what 'testConnection' entails (e.g., network call, authentication check), potential side effects, error conditions, or rate limits. However, it doesn't contradict the annotations, so it meets the lower bar with annotations present but adds minimal value.

  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 brief and structured with a clear header and parameter list, avoiding unnecessary verbosity. However, it's under-specified rather than concise—the content is sparse, but what's present is efficiently formatted without wasted words. It could be more informative without losing conciseness.

  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 purpose (testing a connection), no output schema, and annotations that don't fully explain behavior, the description is incomplete. It lacks details on what the test validates, what the return value indicates (e.g., success/failure, error messages), and how parameters affect the test. For a tool that likely involves external system interaction, this leaves the agent with insufficient context to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters 'giteaId' and 'organizationName' as optional but provides no semantic meaning—what these parameters represent, how they relate to testing a connection, or what happens if omitted. Without this, the agent cannot understand when or how to use these parameters effectively, leaving significant gaps despite the low parameter count.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[gitea] gitea.testConnection (POST)' restates the tool name and HTTP method but doesn't explain what 'testConnection' actually does. It doesn't specify what resource is being tested (e.g., Gitea provider configuration), what 'test' means (e.g., validate connectivity/credentials), or what the outcome indicates. This is essentially a tautology that adds little beyond the name itself.

  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 is provided about when to use this tool versus alternatives. There are sibling tools like 'dokploy_gitea_create', 'dokploy_gitea_update', and other provider test tools (e.g., 'dokploy_bitbucket_testConnection'), but the description doesn't differentiate this tool's specific use case or mention prerequisites like needing an existing Gitea provider configuration. Usage is implied only by the name 'testConnection'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitlab_oneC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying 'GET', which aligns with annotations but doesn't add meaningful details like rate limits, authentication needs, or what 'gitlab.one' refers to. No contradiction with annotations exists.

  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 with two lines, front-loading the tool context ('[gitlab] gitlab.one (GET)') and listing the parameter. There's no wasted text, but it's overly terse, bordering on under-specification rather than efficient communication.

  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 has no output schema and annotations cover basic safety, the description is incomplete. It lacks details on what the tool returns, error conditions, or how it fits into the broader GitLab context. For a tool with 1 parameter and 0% schema coverage, more explanation is needed to be fully helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only defines 'gitlabId' as a required string with minLength 1. The description lists the parameter but adds no semantics—it doesn't explain what 'gitlabId' represents, its format, or examples. This fails to compensate for the low schema coverage, leaving the parameter poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[gitlab] gitlab.one (GET)' which partially indicates it's a GET operation related to GitLab, but it's vague about what specific resource or action it performs. It doesn't distinguish from sibling tools like 'dokploy_gitlab_create' or 'dokploy_gitlab_update' beyond implying it's a read operation. The description is more of a label than a clear purpose statement.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or comparisons to sibling tools (e.g., 'dokploy_gitlab_getGitlabRepositories' or 'dokploy_gitlab_gitlabProviders'). The agent must infer usage from the name and annotations alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitProvider_getAllC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds no behavioral context beyond what annotations declare (e.g., no rate limits, auth needs, or return format). However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is under-specified rather than concise. It wastes characters on redundant information ('[gitProvider]' and '(GET)') without adding meaningful content. A single sentence like 'Retrieve all configured git providers' would be more effective. This is inefficient use of limited description space.

  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's simplicity (0 parameters, annotations covering safety), the description is minimally adequate but lacks completeness. It doesn't explain what 'git providers' are in this context or what the output looks like (no output schema). For a read-only list operation, more context about the returned data would be helpful, though annotations reduce the burden.

  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 0 parameters with 100% schema description coverage (empty schema). The description doesn't add parameter details, but with no parameters, the baseline is 4. There's no need to compensate for missing parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[gitProvider] gitProvider.getAll (GET)' is a tautology that restates the tool name and adds minimal context (GET method). It doesn't specify what resource is being retrieved (e.g., 'list all configured git providers'), nor does it distinguish from sibling tools like dokploy_gitProvider_remove. The purpose remains vague beyond the obvious 'get all' operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 provides no context about prerequisites, typical use cases, or relationships with sibling tools (e.g., dokploy_gitProvider_remove for deletion). This leaves the agent with no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_updateCustomC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key behavioral hints: readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), and openWorldHint=true (flexible inputs). The description adds no behavioral context beyond this, such as what 'update' entails (e.g., partial vs. full updates), side effects, or error conditions. Since annotations cover the core safety profile, the description meets the lower bar but doesn't enhance understanding of the tool's behavior in practice.

  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 and structured as a parameter list, which is efficient for a tool with many inputs. However, it lacks a clear introductory sentence stating the tool's purpose, making it slightly less front-loaded than ideal. The formatting with bullet points is helpful, but the content is under-specified rather than overly verbose, keeping it relatively tight.

  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 (13 parameters, 0% schema coverage, no output schema) and the mutation nature (readOnlyHint=false), the description is inadequate. It doesn't explain what the tool returns, how updates affect existing configurations, or the relationships between parameters (e.g., if 'endpoint' is required when certain booleans are true). With rich annotations but no output schema and poor parameter documentation, the description leaves significant gaps for an agent to understand the tool's full context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 by explaining parameters. It only lists parameter names and types without any semantic meaning (e.g., what 'appBuildError' controls or how 'endpoint' is used). This adds minimal value beyond the schema, failing to clarify the purpose of the 13 parameters, especially the many boolean flags that likely toggle notification events. With low coverage, a higher score requires meaningful explanations, which are absent here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is essentially a tautology that restates the tool name ('notification.updateCustom') with minimal additional context. It mentions 'POST' and lists parameters but doesn't clearly state what the tool actually does (e.g., updating custom notification settings for specific events). While it implies updating something related to notifications, it lacks a specific verb+resource combination that distinguishes its purpose from sibling tools like other notification update tools.

  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 doesn't mention prerequisites (e.g., needing an existing custom notification), context for updates (e.g., modifying event triggers or endpoints), or comparisons with other notification tools (e.g., dokploy_notification_updateDiscord). Without this, an agent must infer usage from the parameter list alone, which is insufficient for clear decision-making.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_port_createC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these annotations, but adds minimal behavioral context beyond the parameter list. It doesn't explain what 'create' entails (e.g., whether it's a persistent configuration, if it affects running applications, or what happens on conflicts). With annotations covering basic safety, the description adds some value through the parameter details but lacks deeper behavioral insights.

  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 brief and structured as a parameter list, which is efficient. However, it lacks a clear purpose statement upfront, forcing the agent to infer functionality from the parameter names. The formatting with brackets and 'POST' is somewhat technical but not wasteful. It could be more front-loaded with intent.

  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?

  For a creation tool with 5 parameters, 0% schema coverage, no output schema, and annotations only covering basic hints, the description is incomplete. It doesn't explain the outcome (what a 'port' is in this context), error conditions, or relationships with other tools. The parameter list helps, but without semantic explanations or usage context, an agent would struggle to use this tool correctly in isolation.

  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 carries the full burden of parameter documentation. It lists all 5 parameters with their types and constraints (enums, required status), which provides essential semantic information not in the schema. However, it doesn't explain what each parameter means (e.g., 'publishedPort' vs 'targetPort', what 'publishMode' choices imply, or how 'applicationId' is used), leaving some interpretation gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name ('port.create') and lists parameters without explaining what the tool actually does. It doesn't specify what resource is being created (a port mapping/configuration for an application) or distinguish it from sibling port tools like dokploy_port_delete or dokploy_port_update. This is essentially a tautology that provides minimal functional insight.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing application), constraints, or relationships with sibling tools like dokploy_port_delete or dokploy_port_update. There's no context about when port creation is appropriate versus other configuration methods.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_rebuildC
  2.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive (destructiveHint=false), non-idempotent (idempotentHint=false), and open-world (openWorldHint=true) operation. The description adds minimal context by specifying it's a POST request, but fails to explain what 'rebuild' entails—whether it involves data loss, reconfiguration, or downtime—or any side effects like service interruption. For a tool with annotations, this leaves significant behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded, with no unnecessary sentences. However, it is under-specified rather than concise, as it lacks essential details about the tool's purpose and usage. The structure is clear but incomplete.

  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 a 'rebuild' operation, the absence of an output schema, and annotations that only partially cover behavior, the description is insufficient. It doesn't explain what the tool returns, potential errors, or the impact on the PostgreSQL instance, leaving the agent with inadequate information to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists the parameter 'postgresId' without adding any meaning. It doesn't clarify what a 'postgresId' is (e.g., a database instance identifier, a configuration ID), its format, or where to obtain it. With low schema coverage, the description fails to compensate for the lack of parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool is for 'postgres.rebuild (POST)', which indicates it rebuilds a PostgreSQL database. This is a specific verb+resource combination, but it doesn't distinguish itself from sibling tools like 'dokploy_postgres_reload' or 'dokploy_postgres_deploy', leaving the exact nature of 'rebuild' ambiguous compared to similar operations.

  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 lacks context about prerequisites, such as whether the PostgreSQL instance must be stopped or in a specific state, and doesn't mention any exclusions or comparisons to sibling tools like 'reload' or 'deploy'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_removeC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds no behavioral context beyond what annotations provide—no information about permissions needed, whether data is permanently deleted, confirmation requirements, or error conditions. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is under-specified rather than concise—it wastes space on redundant information like '[postgres]' and '(POST)' while providing minimal useful content. The structure is poor with a parameter list that adds no value beyond the schema. It lacks front-loaded, actionable information and includes unnecessary formatting that doesn't aid understanding.

  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?

  For a destructive tool with 1 parameter and no output schema, the description is inadequate. It doesn't explain the consequences of removal, what 'postgresId' refers to, or what the tool returns. Annotations cover safety aspects, but the description fails to provide necessary operational context, making it incomplete for safe and correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the parameter 'postgresId' is undocumented in the schema. The description only repeats the parameter name without explaining what it represents (e.g., a database ID, name, or UUID), where to find it, or format requirements. This fails to compensate for the schema's lack of documentation, leaving the parameter's meaning unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a PostgreSQL instance, which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'dokploy_postgres_delete' or 'dokploy_postgres_remove' (if both existed), and the title/name repetition adds minimal value. The purpose is understandable but lacks specificity about what 'remove' entails compared to similar operations.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when removal is appropriate, or what happens after removal. With many sibling tools for PostgreSQL management (create, deploy, update, etc.), the agent receives no help in selecting this specific destructive operation over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_stopC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is not read-only, not destructive, not idempotent, and open-world. The description adds that it's a POST operation, which implies mutation, aligning with readOnlyHint=false. However, it doesn't clarify what 'stop' means behaviorally (e.g., graceful shutdown, service interruption, or data persistence). With annotations covering safety aspects, the description provides minimal additional 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 brief and structured with a clear parameter list, avoiding unnecessary verbosity. However, it could be more front-loaded with the tool's purpose rather than starting with bracketed context. It efficiently conveys the HTTP method and parameter but misses an introductory explanation.

  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 potential impact (stopping a database) and lack of output schema, the description is insufficient. It doesn't explain the outcome (e.g., success/failure indicators, error conditions) or side effects. With annotations providing some safety context but no behavioral details, the description leaves critical gaps for an agent to use the tool effectively.

  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 0%, but the description lists the parameter 'postgresId' as required. It doesn't explain what this ID represents (e.g., instance identifier, database name) or where to obtain it. With only one parameter and no schema descriptions, the description adds basic acknowledgment but lacks meaningful semantic details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('postgres.stop') without adding meaningful context about what 'stop' entails. It mentions the HTTP method (POST) but doesn't clarify whether this stops a running PostgreSQL instance, pauses it, or terminates it. The purpose is tautological rather than explanatory.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like 'dokploy_postgres_start' or 'dokploy_postgres_changeStatus'. The description lacks any context about prerequisites, dependencies, or scenarios where stopping PostgreSQL is appropriate versus other actions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_project_updateC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide hints: readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), openWorldHint=true (accepts unknown parameters). The description adds no behavioral context beyond these annotations, such as permission requirements, rate limits, or side effects. It doesn't contradict annotations, but offers no additional value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is poorly structured: it starts with '[project] project.update (POST)' which is redundant with the name/title, followed by a parameter list that duplicates schema information without adding value. It's not front-loaded with useful information and includes unnecessary formatting, making it inefficient.

  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 (6 parameters, mutation operation), lack of output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the update behavior, what happens to unspecified fields, or the response format. Annotations help but don't compensate for missing usage and parameter details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters but only as names and types (e.g., 'projectId (string, required)'), adding minimal semantics like optionality. It fails to explain what each parameter does (e.g., 'env' meaning environment), leaving significant gaps for a tool with 6 parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'project.update (POST)' which indicates it updates a project, but it's vague about what specific fields can be updated and doesn't distinguish it from other project-related tools like 'dokploy_project_create' or 'dokploy_project_remove'. The verb 'update' is clear but lacks specificity about the resource scope beyond 'project'.

  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 is provided on when to use this tool versus alternatives. With siblings like 'dokploy_project_create', 'dokploy_project_remove', and 'dokploy_project_search', the description doesn't indicate prerequisites, such as needing an existing project, or differentiate its use case from other update tools in the system.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_stopC
  2.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is not read-only, not destructive, not idempotent, and open-world, but the description adds no behavioral context beyond the basic action. It doesn't explain what 'stop' entails (e.g., graceful shutdown, data persistence, service interruption), whether it requires specific permissions, or what happens on repeated calls, missing critical details for a state-changing operation.

  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 brief and front-loaded with the tool name and HTTP method, avoiding unnecessary verbosity. However, the formatting with brackets and parentheses is slightly cluttered, and it could be more polished while remaining concise.

  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 (state-changing operation), lack of output schema, and minimal annotations, the description is incomplete. It doesn't cover behavioral aspects like effects, error conditions, or return values, leaving significant gaps for the agent to understand the tool's full context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'redisId' as a required parameter without adding any semantic meaning. It doesn't explain what a 'redisId' is (e.g., a UUID, name, or identifier format), where to find it, or its constraints, failing to compensate for the lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool stops a Redis instance ('redis.stop') and identifies the required parameter, which clarifies the basic action. However, it doesn't distinguish this from sibling tools like 'dokploy_redis_start' or 'dokploy_redis_changeStatus', leaving ambiguity about when to choose this specific stop function over alternatives.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., Redis must be running), exclusions (e.g., cannot stop if in use), or comparisons to sibling tools like 'dokploy_redis_changeStatus' or 'dokploy_application_stop', leaving the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_withSSHKeyC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide comprehensive behavioral information (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the bar is lower. The description adds minimal value by indicating this is a GET operation, which aligns with the read-only annotation. However, it doesn't provide any additional behavioral context beyond what the annotations already declare.

  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 extremely concise (just 5 words), but this brevity comes at the cost of clarity. While it's front-loaded with the essential operation type (GET), it's under-specified rather than efficiently informative. Every word earns its place, but more words would be needed to make this truly helpful.

  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 the Dokploy system with over 200 tools, this description is inadequate. While annotations provide good behavioral coverage and there are no parameters to explain, the description fails to explain what this tool actually returns or how it fits into the broader context. Without an output schema, the description should at least hint at the return value, but it provides no such information.

  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 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters since there are none, and the empty input schema is fully documented. The description's mention of 'GET' operation is appropriate but doesn't add significant parameter semantics beyond what's already clear from the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[server] server.withSSHKey (GET)' is tautological - it essentially restates the tool name with minimal additional context. While it indicates this is a GET operation related to servers and SSH keys, it doesn't specify what the tool actually does (e.g., retrieve server SSH key information, list servers with SSH keys, etc.). It fails to distinguish this tool from its many siblings in the Dokploy system.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. With over 200 sibling tools in the Dokploy system, including other SSH key tools (dokploy_sshKey_all, dokploy_sshKey_one, etc.) and server tools (dokploy_server_all, dokploy_server_one, etc.), the agent receives no indication of this tool's specific use case or how it differs from related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getDokployCloudIpsC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true). The description adds no additional behavioral context beyond what's in annotations. It doesn't mention rate limits, authentication requirements, or what format the cloud IPs are returned in. With annotations doing the heavy lifting, the description adds minimal value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While technically concise (one bracketed phrase), the description is under-specified rather than efficiently informative. The '[settings]' prefix adds minimal value, and the rest merely repeats the tool name with '(GET)' appended. It fails to front-load essential information about what the tool actually does.

  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 has zero parameters, comprehensive annotations, but no output schema, the description is minimally adequate. It identifies the tool as a GET operation under settings, but doesn't explain what 'DokployCloudIps' are or what format they're returned in. For a simple read-only tool with good annotations, this is the bare minimum.

  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 schema description coverage is 100% (empty schema). With no parameters to document, the description doesn't need to add parameter semantics. The baseline for zero parameters is 4, as there's nothing to compensate for and no schema gaps to fill.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.getDokployCloudIps (GET)' is a tautology that restates the tool name and adds minimal context. It indicates this is a GET operation under settings, but doesn't specify what 'DokployCloudIps' are or what the tool actually retrieves. Compared to sibling tools like 'dokploy_settings_getIp' or 'dokploy_settings_getTraefikPorts', it doesn't clearly differentiate its specific purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context, or comparison to similar tools like 'dokploy_settings_getIp' or 'dokploy_server_publicIp'. The agent receives no help in determining when this specific cloud IP retrieval tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getLogCleanupStatusC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=true, destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description doesn't contradict these but adds minimal behavioral context—it only states 'GET', implying a read operation. However, it doesn't explain why destructiveHint=true (e.g., if fetching status triggers cleanup or has side effects) or provide details on rate limits, authentication needs, or output format. With annotations covering safety and idempotency, the description adds some value but not rich behavioral insights.

  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 concise but under-specified—it's a single bracketed phrase with minimal information. While not verbose, it fails to convey essential details, making it inefficient in terms of usefulness. It's structured as a code-like reference rather than a helpful description, which limits its effectiveness.

  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 simplicity (0 parameters, annotations provided), the description is incomplete. It lacks explanation of what 'log cleanup status' entails, the return value (no output schema), or how it fits into the broader system (e.g., related to 'dokploy_settings_updateLogCleanup'). With annotations, some context is covered, but the description doesn't compensate for missing output details or operational 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?

  The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, so it meets the baseline for a parameterless tool. No additional parameter information is required or provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.getLogCleanupStatus (GET)' is tautological—it essentially restates the tool name and adds the HTTP method. It doesn't specify what the tool actually does (e.g., retrieves the current status of log cleanup settings or checks if log cleanup is enabled). While it hints at a 'settings' context, the purpose remains vague compared to what a clear description would provide.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, related tools (e.g., 'dokploy_settings_updateLogCleanup' for updating), or typical scenarios for checking log cleanup status. This leaves the agent without direction on appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_readWebServerTraefikConfigC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description doesn't need to repeat these. However, it adds minimal value by implying a read operation ('readWebServerTraefikConfig') and specifying 'GET', which aligns with annotations. It doesn't disclose additional behavioral traits like what exactly is read, format of returned data, or any constraints. No contradiction with annotations exists.

  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 concise but under-specified—it's a single bracketed phrase that doesn't effectively communicate purpose. While it's brief, it fails to be informative, making it less helpful than a slightly longer but clearer description. It's front-loaded but lacks substance.

  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 implied by the tool name (reading web server Traefik configuration) and the absence of an output schema, the description is incomplete. It doesn't explain what the tool returns, the scope of the configuration read, or how it differs from similar tools. Annotations cover safety aspects, but the description doesn't add enough context for effective use.

  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 input schema has 0 parameters with 100% coverage, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion. A baseline of 4 is appropriate for a tool with no parameters, as there's nothing to compensate for.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.readWebServerTraefikConfig (GET)' is a tautology that restates the tool name and adds minimal context. It mentions 'settings' and 'readWebServerTraefikConfig' but doesn't clearly state what the tool does beyond implying it reads something related to web server Traefik configuration. It lacks a specific verb-resource combination that distinguishes it from sibling tools like 'dokploy_settings_readTraefikConfig' or 'dokploy_settings_updateWebServerTraefikConfig'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions. With many sibling tools in the settings category (e.g., 'dokploy_settings_readTraefikConfig', 'dokploy_settings_updateWebServerTraefikConfig'), there's no indication of how this tool differs or when it should be selected over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sso_addTrustedOriginC
  2.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond what annotations provide—it doesn't explain what 'trusted origin' entails, potential side effects, authentication requirements, or rate limits. For a mutation tool with annotations, this is a minimal disclosure.

  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 brief but inefficiently structured—it repeats the tool name and HTTP method without adding value. The parameter listing is minimal but not front-loaded with critical information. It avoids verbosity but under-specifies key details.

  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 (SSO configuration mutation), lack of output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the purpose of 'trusted origin', expected outcomes, error conditions, or how it fits into SSO workflows. Annotations help but don't fill these gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description lists 'origin' as a required string but adds no meaning—it doesn't explain what an 'origin' is (e.g., URL format, validation rules) or its role in SSO. This fails to compensate for the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool adds a trusted origin for SSO, which is a clear verb+resource combination ('addTrustedOrigin' for 'sso'). However, it doesn't distinguish this from sibling SSO tools like 'dokploy_sso_removeTrustedOrigin' or 'dokploy_sso_getTrustedOrigins' beyond the basic action implied by the name. The description is vague about what 'trusted origin' means in context.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., SSO configuration), exclusions, or related tools like 'dokploy_sso_removeTrustedOrigin' for removal. It leaves the agent to infer usage from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_stripe_createCustomerPortalSessionC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds no behavioral context beyond the HTTP method (POST), which aligns with the annotations but doesn't provide additional details like authentication needs, rate limits, or what the session enables. With annotations covering basic traits, the description adds minimal value.

  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, compact string but under-specified—it lacks essential purpose and usage information. While not verbose, it fails to convey necessary context efficiently, making it less helpful than a well-structured, concise description would be.

  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 likely complexity (creating a Stripe customer portal session) and lack of output schema, the description is incomplete. It doesn't explain what the session is for, what it returns, or any side effects. Annotations provide basic hints, but the description fails to add meaningful context for an agent to understand the tool's role.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate. Baseline is 4 for zero parameters, as there's nothing to compensate for.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[stripe] stripe.createCustomerPortalSession (POST)' restates the tool name with minimal context. It indicates the service (Stripe) and HTTP method but lacks a clear verb-resource statement explaining what the tool actually does (e.g., creates a customer portal session for billing management). This is closer to a tautology than a meaningful description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool, what prerequisites exist, or alternatives. Given the sibling tools include other Stripe-related tools (e.g., createCheckoutSession, getCurrentPlan), there is no differentiation to help an agent choose appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_stripe_getInvoicesC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true) already indicate this is a safe, repeatable read operation with open-world semantics. The description adds minimal behavioral context by specifying 'GET', which aligns with read-only but doesn't provide additional details like rate limits, authentication needs, or return format. No contradiction with annotations exists, but the description adds little beyond them.

  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 extremely concise ('[stripe] stripe.getInvoices (GET)'), which could be efficient if it were informative. However, it under-specifies the tool's purpose and usage, making it feel incomplete rather than optimally brief. It's front-loaded but lacks substance, so it doesn't fully earn its place.

  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 (a Stripe API call) and lack of output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., invoice list, format, pagination) or any behavioral nuances. Annotations cover safety, but the description fails to provide necessary context for effective use, especially compared to richer sibling tools.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate. Baseline for 0 parameters is 4, as the schema fully covers the absence of inputs, and the description doesn't need to compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[stripe] stripe.getInvoices (GET)' restates the tool name and adds minimal context (stripe prefix and GET method). It indicates the tool retrieves invoices from Stripe but lacks specificity about scope (e.g., all invoices, filtered, paginated) and doesn't differentiate from potential siblings like other Stripe-related tools (e.g., dokploy_stripe_getProducts). This is closer to a tautology with minor elaboration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., Stripe integration setup), context (e.g., for billing management), or exclusions (e.g., not for creating invoices). Given the sibling list includes other Stripe tools (e.g., dokploy_stripe_getProducts, dokploy_stripe_createCheckoutSession), the absence of differentiation is a significant gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_swarm_getNodeInfoC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context with '(GET)', implying a read operation that aligns with annotations. However, it doesn't disclose additional traits like rate limits, authentication needs, or what 'NodeInfo' entails, leaving gaps despite the annotations.

  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 and structured with a clear header and parameter list, avoiding unnecessary verbosity. However, it could be more front-loaded by starting with the tool's purpose rather than technical details like '[swarm]'. The efficiency is good, but the structure prioritizes metadata over actionable information.

  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 implied by swarm operations and 0% schema coverage, the description is incomplete. It lacks details on what 'NodeInfo' returns, error conditions, or dependencies. With no output schema and minimal parameter explanation, an agent cannot fully understand how to use this tool effectively in context, especially compared to siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and no output schema, the description lists parameters (nodeId, serverId) but provides no semantic meaning. It doesn't explain what these IDs represent, their format, or how they affect the query. For example, it's unclear if serverId scopes the node lookup or is optional for filtering. This fails to compensate for the schema's lack of descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states '[swarm] swarm.getNodeInfo (GET)' which is essentially a tautology of the tool name, providing minimal additional context. It mentions 'GET' which implies a read operation, but doesn't specify what 'NodeInfo' actually contains or what resource it retrieves. While it distinguishes from some siblings by focusing on 'swarm' and 'node', it lacks the specificity needed for clear understanding.

  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 guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, such as needing swarm cluster access, or differentiate it from similar tools like 'dokploy_swarm_getNodes' or 'dokploy_cluster_getNodes' in the sibling list. Without this context, an agent cannot make informed decisions about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_whitelabeling_getPublicC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds minimal behavioral context beyond what annotations already provide. Annotations clearly indicate this is a read-only, non-destructive, idempotent, open-world operation. The description only adds that it's a GET request, which aligns with readOnlyHint=true. However, it doesn't provide any additional behavioral details such as what 'public' means in this context, whether authentication is required, rate limits, or what specific data is returned. With comprehensive annotations covering the core safety profile, the description adds some value but remains limited.

  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 extremely concise - arguably too concise. While it contains no wasted words, it's under-specified rather than appropriately concise. The single bracketed phrase '[whitelabeling] whitelabeling.getPublic (GET)' doesn't provide enough meaningful information. It's front-loaded in the sense that all information is presented immediately, but that information is insufficient for the agent to understand the tool's purpose and usage.

  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 that this is a zero-parameter tool with comprehensive annotations but no output schema, the description is incomplete. While annotations cover safety aspects, the description fails to explain what 'getPublic' actually retrieves, what 'public' means in this whitelabeling context, or what the return format looks like. For a tool that presumably returns whitelabeling configuration data, the description should specify what kind of data is returned and in what context 'public' applies.

  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 with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters since none exist. According to the scoring rules, zero parameters warrants a baseline score of 4, as there's no parameter information to provide beyond what the schema already documents (which is that there are no parameters).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[whitelabeling] whitelabeling.getPublic (GET)' is essentially a tautology that restates the tool name and title with minimal additional context. It mentions 'whitelabeling' and 'getPublic' but doesn't explain what 'public' refers to or what specific whitelabeling data is retrieved. While it includes the HTTP method '(GET)', this doesn't meaningfully clarify the tool's purpose beyond what's already implied by 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or differentiate it from sibling tools like 'dokploy_whitelabeling_get' or 'dokploy_whitelabeling_update'. The agent receives no information about appropriate use cases or when this specific 'getPublic' variant should be selected over other whitelabeling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_whitelabeling_resetC
  2.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide valuable information: readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true (safe to retry), openWorldHint=true (handles unknown inputs). The description adds minimal behavioral context beyond this - it indicates a POST operation and mentions 'reset', but doesn't clarify what gets reset, whether this affects system state, or what the expected outcome is. With annotations covering the safety profile, the description adds some value but lacks operational details.

  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 extremely concise - just 5 words - but this brevity comes at the cost of clarity. While it's front-loaded with the resource category, it lacks the explanatory content needed for an agent to understand the tool's purpose. The structure shows the resource and method but doesn't provide meaningful operational context. It's concise but under-specified rather than efficiently informative.

  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?

  For a mutation tool (readOnlyHint=false) with no output schema, the description is inadequate. It doesn't explain what 'reset' means operationally, what gets reset, what the expected outcome is, or whether there are side effects. While annotations provide safety information, the description fails to give the agent enough context to understand when and why to use this tool versus the other whitelabeling tools. Given the complexity implied by 'reset' operations and lack of output documentation, more completeness is needed.

  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 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain parameters since none exist. However, it could potentially mention that no input is required, which would be helpful context. Given the zero-parameter scenario, a baseline of 4 is appropriate as the description doesn't need to compensate for any parameter documentation gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[whitelabeling] whitelabeling.reset (POST)' is essentially a tautology that restates the tool name and HTTP method without explaining what 'reset' means in this context. It doesn't specify what resource is being reset (whitelabeling settings? configurations?) or what the reset action entails. While it mentions the resource category ('whitelabeling'), it lacks a clear verb-object relationship that would help an agent understand the specific operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides zero guidance on when to use this tool versus alternatives. There are sibling tools like 'dokploy_whitelabeling_get', 'dokploy_whitelabeling_getPublic', and 'dokploy_whitelabeling_update', but the description doesn't explain when a reset is appropriate versus getting or updating whitelabeling settings. No context, prerequisites, or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_destination_allC
  2.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear behavioral hints (read-only, non-destructive, idempotent, open-world), which cover safety and idempotency. The description adds no additional behavioral context, but since annotations are comprehensive, the bar is lower. There is no contradiction with annotations (e.g., it doesn't imply mutation), so the description doesn't detract, but it also doesn't supplement with details like rate limits or authentication needs. With good annotations, a 4 reflects that the description doesn't add value but doesn't mislead.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief ('[destination] destination.all (GET)'), but this brevity stems from under-specification rather than efficient communication. It fails to convey purpose or usage, making it ineffective. While not verbose, it lacks the necessary content to be considered concise in a helpful way—it's more of a placeholder than a structured description.

  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 simplicity (no parameters, read-only) and rich annotations, the description is incomplete. It does not explain what 'destination.all' returns (e.g., a list of destinations), and there is no output schema to compensate. For a tool that likely returns data, the description should at least hint at the return type or purpose. The annotations help, but the description leaves too much ambiguity for an agent to use it confidently.

  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 schema description coverage is 100% (empty schema). With no parameters to document, the description cannot add parameter semantics. The baseline for zero parameters is 4, as there is no need for parameter explanation. The description does not mention parameters, which is appropriate here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[destination] destination.all (GET)' is tautological—it essentially restates the tool name and adds the HTTP method, which is redundant with naming conventions. It fails to specify what the tool actually does (e.g., list all destinations, fetch destination configurations) or distinguish it from sibling tools like 'dokploy_destination_one' or 'dokploy_destination_create'. This provides minimal actionable information beyond the name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., after creating a destination), or comparisons to sibling tools (e.g., 'dokploy_destination_one' for a single destination). Without any usage instructions, an agent cannot make informed decisions about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getWebServerSettingsC
  2.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true) already indicate this is a safe, non-destructive, idempotent read operation. The description adds minimal behavioral context by specifying 'GET', which aligns with the annotations. However, it does not provide additional details like rate limits, authentication needs, or response format, which would be beneficial given the lack of an output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description '[settings] settings.getWebServerSettings (GET)' is overly concise to the point of being cryptic and under-specified. It lacks complete sentences or clear structure, making it difficult to parse and understand without additional context. While brief, it fails to effectively communicate purpose or usage.

  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 simplicity (0 parameters, good annotations), the description is incomplete. It does not explain what 'web server settings' includes, the expected output format, or any behavioral nuances beyond the annotations. With no output schema, the description should ideally clarify the return value, but it does not, leaving gaps in understanding for the 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?

  The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description does not add parameter information, which is unnecessary here. A baseline of 4 is appropriate for a zero-parameter tool where the schema already covers everything.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.getWebServerSettings (GET)' is tautological, essentially restating the tool name with minimal additional context. It indicates a GET operation on web server settings but lacks specificity about what 'web server settings' entails or what resource it targets, failing to clearly distinguish it from sibling tools like 'dokploy_settings_readWebServerTraefikConfig' or 'dokploy_settings_updateWebServerTraefikConfig'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for usage, or comparisons to sibling tools (e.g., other settings-related tools in the list), leaving the agent with no information to make an informed selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_healthC
  2.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive behavioral hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds minimal value by specifying '(GET)', which aligns with the read-only annotation. However, it doesn't disclose any additional behavioral traits like what 'health' encompasses, response format, or potential error conditions. The description doesn't contradict annotations, so no contradiction flag is raised.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While brief, the description is under-specified rather than concise. The single bracketed phrase '[settings] settings.health (GET)' is cryptic and doesn't form a complete sentence or clear explanation. It fails to front-load essential information about the tool's purpose, making it inefficient despite its short length.

  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 simplicity (0 parameters, good annotations), the description is incomplete. It lacks explanation of what 'health' means in this context, what the output contains, or why this tool exists among many settings siblings. Without an output schema, the description should ideally hint at the return value, but it doesn't. The annotations help, but the description leaves significant gaps for agent 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?

  The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it doesn't attempt to do so. A baseline of 4 is appropriate since there are no parameters to explain, and the schema coverage is complete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.health (GET)' is a tautology that restates the tool name and title without adding meaningful purpose. It mentions 'settings' and 'health' but doesn't specify what health information is retrieved or what resource is involved. While it includes the HTTP method '(GET)', this doesn't clarify the actual function beyond what's already implied by 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 Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools in the 'settings' category (e.g., dokploy_settings_getDokployVersion, dokploy_settings_getWebServerSettings), there's no indication of what distinguishes this health check from other settings-related tools. The agent receives no usage context or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_haveRootAccessC
  2.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the bar is lower. The description adds minimal context by specifying it's a GET operation, which aligns with read-only behavior. However, it doesn't disclose additional traits like authentication requirements, rate limits, or what 'root access' entails in this system. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While concise, the description is under-specified rather than efficiently structured. It's a single bracketed phrase that fails to convey meaningful information beyond the tool name. Conciseness should not come at the cost of clarity; this is too sparse to be helpful.

  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 simplicity (0 parameters, rich annotations) but lack of output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a boolean indicating root access status, or an error if unauthorized). For a permission-checking tool, this omission is significant, as the agent needs to know how to interpret the result.

  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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required by not mentioning any. It meets the baseline expectation for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[user] user.haveRootAccess (GET)' is essentially a tautology that restates the tool name with minimal added context. It indicates a GET operation related to user root access but lacks a clear, specific verb-resource statement explaining what the tool actually does (e.g., 'Check if the current user has root/administrative access privileges'). It doesn't distinguish this tool from sibling user tools like dokploy_user_get or dokploy_user_getPermissions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There are no indications of prerequisites, context for invocation, or comparisons with sibling tools (e.g., dokploy_user_getPermissions for detailed permissions). It's a bare statement with zero usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_ai_createC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a write operation (readOnlyHint=false), non-destructive, non-idempotent, and open-world. The description doesn't add behavioral context beyond what annotations provide (e.g., no mention of authentication requirements, rate limits, or what happens on duplicate creation). However, it doesn't contradict annotations, so it meets the baseline for having annotations.

  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 brief but inefficiently structured. It starts with redundant tool naming, then lists parameters without context. While concise, it lacks front-loaded purpose and wastes space on basic parameter types that the schema already defines.

  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?

  For a creation tool with 5 required parameters, 0% schema coverage, no output schema, and no annotations explaining behavior, the description is inadequate. It doesn't explain what resource is created, what the parameters mean, or what to expect upon success/failure, leaving significant gaps for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameter names and types but provides no semantic meaning (e.g., what 'apiUrl' should point to, what 'model' refers to, or what 'isEnabled' controls). This adds minimal value beyond the schema's structural information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name '[ai] ai.create (POST)' but doesn't explain what it actually creates. It mentions parameters but not the resource being created (e.g., an AI configuration, model deployment, or integration). While 'create' implies a creation action, the specific purpose remains vague without stating what is being created in the Dokploy context.

  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 is provided on when to use this tool versus alternatives. With sibling tools like dokploy_ai_get, dokploy_ai_update, and dokploy_ai_delete, the description doesn't differentiate this create operation from other AI-related operations or explain prerequisites (e.g., whether an existing AI configuration is needed).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_deleteC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, which the description doesn't contradict. However, it adds no behavioral context beyond what annotations provide, such as explaining what 'delete' entails (e.g., permanent removal, side effects, or confirmation requirements), leaving gaps in understanding the tool's impact.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) and a sparse parameter list that adds little value. While not verbose, it could be more structured and informative without sacrificing conciseness.

  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 destructive nature (annotations hint at this), one parameter with no schema descriptions, no output schema, and many sibling tools, the description is incomplete. It lacks critical details like success/error responses, dependencies, or safety warnings, making it inadequate for informed use in this complex environment.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and one parameter, the description only lists 'applicationId' as required without adding meaning, such as what an application ID is, where to find it, or format examples. This fails to compensate for the schema's lack of descriptions, leaving the parameter's semantics unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool deletes an application ('application.delete') and specifies the required parameter 'applicationId', which clarifies the verb and resource. However, it doesn't distinguish this from sibling deletion tools like 'dokploy_compose_delete' or 'dokploy_ai_delete', leaving the scope vague beyond the generic 'application' term.

  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 guidance on when to use this tool versus alternatives, such as other deletion tools in the sibling list (e.g., 'dokploy_application_cancelDeployment' or 'dokploy_application_remove'). It also lacks prerequisites, warnings, or context for invoking this destructive operation, offering minimal usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_disconnectGitProviderC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these but adds minimal behavioral context—it specifies it's a POST request, implying a mutation, but doesn't detail effects like whether it removes Git integration, impacts deployments, or requires specific permissions. With annotations covering basic hints, the description adds some value 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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, bullet points) that doesn't add value. It's concise but could be more structured and informative, as the parameter listing is minimal and doesn't enhance clarity.

  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 (a mutation with no output schema and 0% schema coverage), the description is inadequate. It lacks details on what disconnecting a Git provider entails, potential side effects, error conditions, or return values. Annotations provide basic hints, but the description doesn't fill the gaps for effective agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists 'applicationId' as a required string but doesn't explain its meaning (e.g., ID format, source, or relation to the application). It adds minimal semantics beyond the schema's structural info, failing to compensate for the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool 'disconnectGitProvider' for an application, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'dokploy_compose_disconnectGitProvider' or explain what disconnecting a Git provider means in this context. The purpose is clear but lacks differentiation and detail.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., if a Git provider must be connected first), exclusions, or related tools like 'dokploy_application_saveGitProvider'. Usage is implied by the name but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_cluster_removeWorkerC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide critical behavioral information: destructiveHint=true (this destroys resources), readOnlyHint=false (it's a mutation), idempotentHint=false (repeated calls may have different effects), and openWorldHint=true (may accept unknown parameters). The description adds no additional behavioral context beyond what annotations already declare - no information about what gets removed, permissions required, or system impact.

  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 technically concise but inefficiently structured. It wastes space repeating the tool name and HTTP method while providing minimal useful information. The parameter listing adds little value without semantic context. While brief, it's not effectively front-loaded with actionable information.

  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?

  For a destructive cluster management tool with 2 parameters (0% schema coverage) and no output schema, this description is inadequate. It doesn't explain what a 'worker' represents in this context, what happens when removed, whether this affects running applications, or what the response contains. The annotations help but don't compensate for the missing operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description must compensate but fails to do so. It merely lists parameter names (nodeId, serverId) without explaining what they represent, their format, or how they relate to the removal operation. The agent cannot understand what values to provide or their significance in the context of worker removal.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a worker from a cluster, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'dokploy_cluster_addWorker' or 'dokploy_cluster_getNodes' - it merely restates the name/title with minimal context. The purpose is clear but lacks sibling differentiation.

  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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites, consequences, or when this operation is appropriate versus other cluster management tools. The agent must infer usage from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_deployment_allByTypeC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, indicating a safe, repeatable read operation with open-world semantics. The description adds minimal behavioral context beyond this, only noting it's a GET request. It does not disclose additional traits like rate limits, authentication needs, or pagination behavior, but it does not contradict the annotations.

  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 brief and front-loaded with the tool name and HTTP method, but it includes a redundant parameter list that mirrors the schema without adding value. The structure is clear but could be more efficient by omitting the parameter enumeration or enhancing it with meaningful explanations.

  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 (2 required parameters, 0% schema coverage, no output schema), the description is insufficient. It lacks details on what the tool returns, error conditions, or how parameters interact. Annotations cover safety, but without output schema or richer parameter explanations, the description leaves significant gaps for effective tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters ('id' and 'type') but does not explain their semantics (e.g., what 'id' refers to, the meaning of 'type' values). It repeats the enum values from the schema without adding context, failing to compensate for the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves deployments by type with a GET request, providing a verb ('allByType') and resource ('deployment'). However, it lacks specificity about what 'allByType' means (e.g., retrieving all deployments of a given type for an ID) and does not distinguish it from sibling tools like 'dokploy_deployment_all' or 'dokploy_deployment_allByCompose', which have similar retrieval purposes but different filtering criteria.

  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 explicit guidance is provided on when to use this tool versus alternatives. The description mentions parameters but does not indicate scenarios for its use, prerequisites, or comparisons with sibling tools such as 'dokploy_deployment_all' (which likely retrieves all deployments without type filtering). This leaves the agent without clear direction on tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_docker_getConfigC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is read-only, non-destructive, idempotent, and open-world, covering key behavioral traits. The description adds minimal value by specifying it's a GET operation, which aligns with annotations, but doesn't disclose additional context like rate limits, authentication needs, or error handling. No contradiction with annotations is present.

  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 brief and structured with a clear header and parameter list, avoiding unnecessary fluff. However, it's under-specified—the purpose statement is minimal, and the parameter details are basic, making it less helpful than it could be without being wasteful.

  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 moderate complexity (2 parameters, no output schema) and rich annotations, the description is incomplete. It fails to explain what 'config' entails, how results are returned, or any usage context, leaving gaps that annotations alone don't cover. This reduces its effectiveness for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameters 'containerId' and 'serverId' with types and required status, adding basic semantics beyond the schema. However, it doesn't explain what these IDs represent (e.g., format, source) or their impact, which is insufficient given the low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves Docker configuration ('getConfig') and specifies it's a GET operation, which clarifies the action. However, it doesn't explain what 'config' means in this context (e.g., container settings, environment variables) or differentiate it from sibling tools like 'dokploy_docker_getContainers', leaving the purpose somewhat vague.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing a running container), use cases (e.g., debugging, inspection), or comparisons to other Docker-related tools in the sibling list, such as 'dokploy_docker_restartContainer'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_environment_removeC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide key behavioral hints: destructiveHint=true (indicates permanent deletion), readOnlyHint=false (confirms mutation), idempotentHint=false (non-idempotent), openWorldHint=true (open world). The description adds minimal value beyond this - it confirms the POST method but doesn't provide additional context about what gets destroyed, recovery options, or side effects. No contradiction with annotations.

  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 brief but poorly structured. It includes the endpoint path '[environment] environment.remove (POST)' which is redundant with the tool name, followed by a basic parameter listing. While concise, it lacks effective front-loading of the most important information about what this tool does and its implications.

  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?

  For a destructive mutation tool with 0% schema coverage and no output schema, the description is insufficient. It doesn't explain what an 'environment' is in this context, what happens when removed, whether there are dependencies or prerequisites, or what the response looks like. The annotations help but don't compensate for the description's gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description only lists 'environmentId' as a required string parameter without explaining what this ID represents, how to obtain it, or format requirements. This is inadequate compensation for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes an environment, which is a specific verb+resource. However, it doesn't distinguish this from sibling tools like 'dokploy_environment_delete' (which doesn't exist in the list) or other removal tools in the system. The purpose is clear but lacks sibling differentiation.

  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 guidance on when to use this tool versus alternatives. There are many sibling tools for deletion/removal (e.g., dokploy_application_delete, dokploy_compose_delete), but no indication of when this specific environment removal tool is appropriate. No prerequisites or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_github_getGithubBranchesC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal context by specifying it's a GET operation, but doesn't disclose behavioral traits like rate limits, authentication needs, pagination, or error handling. No contradiction with annotations exists.

  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 brief and structured with a parameter list, but includes redundant information like '[github]' and '(GET)' that doesn't add value. It's front-loaded with the tool name but could be more efficient by integrating parameter details into a cohesive sentence. No wasted sentences, but room for improvement.

  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 has 3 parameters with 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is incomplete. It lacks details on parameter meanings, expected output (e.g., list of branch names with metadata), error conditions, and integration context (e.g., how githubId relates to configured providers).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description lists parameters (repo, owner, githubId) with types and required status, adding basic semantics. However, it doesn't explain what these parameters mean (e.g., owner is the GitHub username/organization, githubId might be a provider ID), their format, or examples, leaving significant gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves GitHub branches, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like dokploy_github_getGithubRepositories or dokploy_bitbucket_getBitbucketBranches, nor does it specify scope (e.g., all branches, default branch only). The inclusion of '[github] github.getGithubBranches (GET)' is redundant with the name/title.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a GitHub provider configured), compare it to similar tools for other Git providers (e.g., dokploy_gitea_getGiteaBranches), or indicate typical use cases (e.g., before deployment).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mongo_createC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, which the description doesn't contradict. However, the description adds minimal behavioral context beyond the parameter list—it doesn't explain what 'create' entails (e.g., provisioning a database, deploying a container), potential side effects, or authentication needs. With annotations covering basic hints, the description adds little value but doesn't mislead.

  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 concise but poorly structured—it's essentially a parameter list without a clear introductory sentence explaining the tool's purpose. While not verbose, it lacks front-loaded information and reads like a schema dump rather than a helpful description. Every sentence (or line) doesn't earn its place due to redundancy with the schema.

  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 (9 parameters, no output schema, annotations only cover basic hints), the description is incomplete. It fails to explain the creation process, return values, error conditions, or how parameters interact. For a creation tool with significant parameter burden and no output schema, more context is needed to guide effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types but adds no semantic meaning—it doesn't explain what 'name', 'environmentId', or other parameters represent, their constraints, or relationships. For 9 parameters with 0% coverage, this is inadequate compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool is for creating a MongoDB resource, which is clear but lacks specificity. It doesn't distinguish this from other 'create' tools (e.g., dokploy_mariadb_create, dokploy_postgres_create) or explain what exactly is being created (e.g., a MongoDB database instance, container, or service). The description is vague about the resource type beyond 'mongo'.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing environment), exclusions, or sibling tools like dokploy_mongo_update or dokploy_mongo_deploy. Usage is implied only by the tool name and parameter list, with no explicit context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_testTelegramConnectionC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is not read-only, not destructive, not idempotent, and is open-world. The description adds no behavioral context beyond what annotations provide—it doesn't explain what 'testTelegramConnection' entails (e.g., sends a test message, validates connectivity, returns success/failure), nor does it mention authentication needs, rate limits, or side effects. With annotations covering basic safety, the description adds minimal value.

  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 brief but inefficiently structured—it repeats the tool name and adds HTTP method without front-loading purpose. The parameter list is formatted but lacks explanatory value. While not verbose, it wastes space on redundant information rather than clarifying the tool's function.

  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 3 parameters with 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is incomplete. It doesn't explain what the tool does, how to use parameters, what to expect as output, or error conditions. For a testing tool with authentication parameters, this leaves significant gaps for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types but adds no semantic meaning—it doesn't explain what 'botToken', 'chatId', or 'messageThreadId' are, their formats, or where to obtain them. This fails to compensate for the schema's lack of descriptions, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name 'notification.testTelegramConnection' and HTTP method 'POST', but lacks a clear verb+resource statement explaining what it actually does. It doesn't specify whether this sends a test message, validates credentials, or performs another Telegram connection test. While it's in the notification context, the purpose remains vague 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 is provided on when to use this tool versus alternatives. There are sibling tools like 'dokploy_notification_createTelegram' and 'dokploy_notification_updateTelegram', but the description doesn't differentiate this testing tool from those creation/update tools or explain prerequisites like needing a configured Telegram notification first.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_removeInvitationC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a destructive, non-idempotent, non-read-only operation with open-world semantics. The description doesn't contradict these but adds minimal behavioral context beyond the name. It mentions the HTTP method (POST) and required parameter, but doesn't elaborate on effects like whether removal is permanent or if there are side effects.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) and a parameter list that doesn't add value. It's somewhat structured but could be more streamlined.

  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 destructive nature (per annotations), one parameter with no schema descriptions, and no output schema, the description is incomplete. It doesn't explain the outcome, error conditions, or provide enough context for safe use, leaving significant gaps for a mutation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'invitationId' as a required string without explaining what it is, where to get it, or its format. This adds little meaning beyond the schema, failing to compensate for the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes an invitation from an organization, which is a specific verb ('removeInvitation') and resource ('organization'). However, it doesn't distinguish this from sibling tools like 'dokploy_organization_inviteMember' or 'dokploy_organization_allInvitations', leaving the purpose somewhat vague in context.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing an existing invitation ID, or when it's appropriate to remove an invitation rather than update or manage it through other means.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_startC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, implying a state-changing action, but doesn't elaborate on behavioral traits beyond what annotations provide (e.g., what 'start' entails, potential side effects, error conditions, or authentication needs). With annotations covering basic hints, the description adds minimal context, warranting a baseline score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is poorly structured, mixing tool context ('[postgres] postgres.start (POST)') with a parameter list in a non-standard format. It's not front-loaded with a clear summary, and the parameter section is redundant with the schema. While brief, it lacks effective organization, making it harder to parse than a simple, well-formed sentence.

  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?

  For a state-changing tool (POST) with no output schema and minimal annotations, the description is insufficient. It doesn't explain what 'start' means operationally, what the expected outcome is (e.g., success/failure indicators), or any dependencies. Given the complexity of managing database instances and the lack of output details, more context is needed for the agent to use this tool effectively.

  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 0%, so the description must compensate. It lists the parameter 'postgresId' as required but provides no semantic meaning (e.g., what constitutes a valid ID, where to find it, format constraints). The schema specifies it's a non-empty string, but the description adds no value beyond restating the parameter name. Given the low coverage, this is inadequate, but the single parameter is straightforward, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool starts a PostgreSQL instance, which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like dokploy_postgres_stop or dokploy_postgres_changeStatus, nor does it specify what 'start' means operationally (e.g., starting a stopped container, initiating a deployment). The purpose is understandable but lacks differentiation and operational clarity.

  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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., the PostgreSQL instance must exist and be stopped), when not to use it (e.g., if already running), or how it relates to sibling tools like dokploy_postgres_stop or dokploy_postgres_changeStatus. The agent must infer usage from context alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_previewDeployment_allC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a read-only, non-destructive, idempotent, and open-world operation, which the description doesn't contradict. However, the description adds no behavioral context beyond what annotations provide—it doesn't explain what a 'preview deployment' entails, whether it returns a list or summary, or any constraints like pagination or rate limits.

  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 brief and structured with a clear parameter list, avoiding unnecessary verbosity. However, it's under-specified—the first part ('[previewDeployment] previewDeployment.all (GET)') is redundant with the name and title, reducing efficiency.

  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 lack of output schema and low schema description coverage (0%), the description is incomplete. It fails to explain what the tool returns (e.g., a list of preview deployments), their structure, or any error conditions. For a tool with one required parameter and no schema documentation, this leaves the agent with insufficient information to use it effectively.

  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 description lists the parameter 'applicationId' as required, matching the input schema. With 0% schema description coverage, the schema provides no details about this parameter. The description adds minimal semantics by stating it's required but doesn't explain its purpose, format, or how it relates to preview deployments, leaving significant gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('previewDeployment.all') without explaining what a 'preview deployment' is or what 'all' refers to. It mentions 'GET' which indicates an HTTP method but doesn't specify the action (e.g., list, retrieve). This is a tautology that provides minimal clarification beyond the name itself.

  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 is provided on when to use this tool versus alternatives. While sibling tools include 'dokploy_previewDeployment_delete', 'dokploy_previewDeployment_one', and 'dokploy_previewDeployment_redeploy', the description doesn't differentiate this 'all' variant from those or suggest any context for its use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_previewDeployment_deleteC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a deletion action. However, the description adds minimal behavioral context beyond what annotations provide—it doesn't explain consequences (e.g., irreversible removal, impact on related resources) or any additional traits like error handling. With annotations covering safety, this earns a baseline score for adding some value through the action description.

  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 brief and front-loaded with the tool name and action, but it includes redundant formatting (brackets and parentheses) that doesn't add clarity. While not verbose, it could be more structured—e.g., separating the purpose from parameter listing. It's concise but could be improved for 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?

  Given the tool's destructive nature (per annotations), no output schema, and 0% schema coverage, the description is incomplete. It lacks details on what a preview deployment is, the deletion's effects, success/error responses, or any dependencies. For a mutation tool with minimal structured data, this leaves significant gaps for an agent to operate safely and effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists 'previewDeploymentId (string, required)' but adds no semantic meaning—it doesn't explain what this ID is, where to find it, or its format. For a single required parameter with no schema documentation, the description fails to compensate adequately, leaving the agent with insufficient information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool deletes a preview deployment, which is a specific verb+resource combination. However, it doesn't distinguish this from other deletion tools in the sibling list (like dokploy_application_delete, dokploy_compose_delete, etc.), nor does it clarify what a 'preview deployment' is in this context. The purpose is clear but lacks differentiation from similar tools.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing preview deployment), when not to use it, or what happens after deletion. With many sibling deletion tools available, this lack of context makes it difficult for an agent to choose appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_oneC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide strong hints (readOnly, non-destructive, idempotent, openWorld), so the bar is lower. The description adds minimal context by specifying it's a GET operation, which aligns with readOnlyHint=true. However, it doesn't disclose additional behavioral traits like what happens if the redisId doesn't exist, rate limits, or authentication requirements beyond what annotations imply.

  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 brief and front-loaded with the core action ('[redis] redis.one (GET)'), but the parameter listing is redundant with the schema and lacks explanatory value. It's concise but under-specified, as more context could improve clarity without adding unnecessary length.

  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 has no output schema, annotations cover safety but not behavioral details, and schema coverage is 0%, the description is incomplete. It doesn't explain what the tool returns (e.g., Redis instance details, status), error conditions, or how it fits into the broader context of Redis management, leaving significant gaps 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.

  Parameters2/5

  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 lists the parameter 'redisId' but provides no semantic meaning (e.g., what constitutes a valid redisId, format, or where to find it). This leaves the parameter poorly understood despite the description attempting to document it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states it's a GET operation for 'redis.one', which implies retrieving a specific Redis resource. However, it doesn't specify what exactly is retrieved (e.g., configuration, status, details) or how it differs from other Redis-related tools like 'dokploy_redis_search' or 'dokploy_redis_update'. The purpose is somewhat clear but lacks specificity and sibling differentiation.

  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 guidance on when to use this tool versus alternatives. There are multiple Redis-related tools (e.g., dokploy_redis_search, dokploy_redis_update) and other 'one' tools (e.g., dokploy_ai_one, dokploy_application_one), but no indication of when this specific GET operation is appropriate or what prerequisites might be required.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_startC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation with open-world semantics. The description adds that it's a POST request, which implies mutation, but doesn't provide behavioral details beyond what annotations already cover. No additional context about side effects, permissions, or response behavior is included, though there's no contradiction with annotations.

  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 brief but inefficiently structured. It includes redundant information like '[redis] redis.start' and formatting that doesn't add value. While not verbose, it fails to front-load critical information and includes unnecessary formatting elements that don't enhance clarity.

  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?

  For a mutation tool with no output schema and 0% parameter documentation coverage, the description is inadequate. It doesn't explain what happens when Redis is started, what success/failure looks like, or any dependencies. Given the annotations provide some behavioral hints but lack full context, the description should do more to compensate for these gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'redisId' as a required string parameter without explaining what this ID represents, how to obtain it, or its format. No additional semantic context is provided beyond the basic schema information, leaving the parameter meaning unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool starts a Redis instance, which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'dokploy_redis_stop' or 'dokploy_redis_changeStatus' - it merely restates the name/title without clarifying what 'start' means in this context (e.g., starting a stopped Redis service vs. initial deployment).

  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 is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., Redis must exist and be stopped), nor does it reference related tools like 'dokploy_redis_stop' or 'dokploy_redis_changeStatus' for status management. Usage context is implied but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_registry_createC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a write operation (readOnlyHint=false) that's non-destructive and non-idempotent. The description doesn't contradict these annotations, but adds minimal behavioral context beyond the parameter list. It doesn't explain what happens on success/failure, whether registry creation is reversible, or any authentication requirements beyond the provided credentials.

  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 reasonably concise with a single-line purpose statement followed by a parameter list. However, the parameter list formatting is inconsistent and the purpose statement could be more front-loaded with essential context. The description wastes space repeating '[registry] registry.create (POST)' which adds little value.

  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?

  For a creation tool with 7 parameters, 0% schema coverage, no output schema, and no annotations explaining behavioral nuances, the description is inadequate. It doesn't explain what the tool returns, what happens on success/failure, or provide any context about registry creation constraints or dependencies. The sibling tools suggest this is part of a larger registry management system, but no integration context is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 7 parameters, the description carries full burden for explaining parameter semantics. While it lists all parameters with basic types, it provides no meaningful context about what each parameter represents (e.g., what registryUrl format is expected, what imagePrefix does, what serverId refers to). The description adds minimal value beyond what's already in the schema structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool creates a registry, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like dokploy_registry_update or dokploy_registry_remove, and the purpose is somewhat vague about what type of registry is being created beyond the 'cloud' registryType parameter.

  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 guidance on when to use this tool versus alternatives. There are multiple sibling registry tools (dokploy_registry_all, dokploy_registry_one, dokploy_registry_remove, dokploy_registry_update, dokploy_registry_testRegistry), but no indication of when this create operation is appropriate versus update or other registry operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_registry_oneC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, non-destructive, repeatable operation. The description adds minimal context by specifying it's a GET request, which aligns with annotations but doesn't disclose additional behavioral traits like error conditions, rate limits, or authentication needs beyond what annotations imply.

  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 brief and front-loaded with the operation type and parameter, but it includes redundant formatting like brackets and parentheses that don't add value. It could be more structured, such as separating the purpose from parameter details, but it avoids unnecessary verbosity.

  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 has one parameter with 0% schema coverage, no output schema, and annotations covering safety, the description is incomplete. It doesn't explain what the tool returns (e.g., registry details), potential errors, or how it fits into the broader context of registry management, leaving gaps for an agent to understand its full use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only defines registryId as a required string. The description mentions 'registryId' but adds no meaning beyond the schema, such as what it represents (e.g., a unique identifier for a registry), format examples, or where to obtain it. With low coverage, the description fails to compensate for the lack of schema details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states it's a GET operation on 'registry.one' with a registryId parameter, which clarifies the verb and resource. However, it doesn't specify what 'registry.one' refers to (e.g., retrieving a specific registry's details) or differentiate it from sibling tools like 'dokploy_registry_all' or 'dokploy_registry_update', leaving the purpose somewhat vague.

  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 lacks context about prerequisites, such as needing an existing registryId, or comparisons to sibling tools like 'dokploy_registry_all' for listing registries or 'dokploy_registry_update' for modifications.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_cleanRedisC
  2.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a destructive (destructiveHint: true), non-idempotent (idempotentHint: false), open-world (openWorldHint: true) write operation (readOnlyHint: false). The description adds no behavioral details beyond these annotations, such as what specifically gets cleaned in Redis, potential side effects, or rate limits. However, since annotations cover key behavioral traits, the description doesn't need to repeat them, and there is no contradiction—it's neutral rather than misleading. A score of 4 reflects that annotations handle the transparency burden adequately, though the description could add context like 'clears all Redis cache data' to enhance value.

  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 extremely concise—just a single line—but it's under-specified rather than efficiently informative. It wastes space on redundant elements like '[settings]' and '(POST)' without providing meaningful content. While brief, it lacks front-loaded clarity, making it less helpful despite its shortness. A score of 3 reflects that it's not verbose but fails to use its limited space effectively.

  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 destructive nature (per annotations) and lack of output schema, the description is incomplete. It doesn't explain what 'cleanRedis' entails, what data is affected, or what the expected outcome is (e.g., success confirmation, error messages). For a destructive operation with no output schema, more context is needed to guide safe usage. The description falls short of providing necessary completeness for an agent to use it confidently.

  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 schema description coverage is 100% (empty schema). The description does not mention parameters, which is appropriate since none exist. According to the rules, with 0 parameters, the baseline score is 4, as there's no need for parameter semantics. The description neither adds nor detracts from parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[settings] settings.cleanRedis (POST)' is tautological—it essentially restates the tool name and adds the HTTP method, which is redundant with annotations. It fails to specify what 'cleanRedis' actually does (e.g., clear Redis cache, reset settings, purge data) or distinguish it from sibling tools like 'dokploy_settings_cleanAll' or 'dokploy_settings_reloadRedis'. This leaves the purpose vague and unhelpful for an agent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 provides no context, prerequisites, or exclusions, and it doesn't reference any sibling tools (e.g., 'dokploy_settings_cleanAll' for broader cleanup). This absence of usage instructions makes it difficult for an agent to decide when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sshKey_removeC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds minimal behavioral context beyond annotations, stating it's a POST operation but not detailing effects like irreversible deletion or permissions required. With annotations covering safety, it adds some value but is sparse.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets and parentheses) and lacks efficient structure. It could be more streamlined without sacrificing clarity.

  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 destructive nature (destructiveHint=true), no output schema, and low schema coverage, the description is incomplete. It fails to explain the outcome of removal, error conditions, or confirmation steps, leaving gaps for a mutation tool with significant behavioral implications.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'sshKeyId' as a required parameter but provides no semantic details, such as what format the ID should be or where to obtain it. This leaves the parameter meaning unclear beyond the schema's basic type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes an SSH key ('sshKey.remove'), which is a specific verb+resource. However, it doesn't differentiate from sibling tools like 'dokploy_sshKey_delete' (which doesn't exist in the list) or other removal tools in the system, making it clear but not sibling-distinctive.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing an existing SSH key ID, or comparisons to other SSH key operations like 'dokploy_sshKey_create' or 'dokploy_sshKey_update'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sshKey_updateC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint: false), non-destructive (destructiveHint: false), idempotent (idempotentHint: true), and open-world (openWorldHint: true) operation. The description doesn't contradict these but adds minimal behavioral context—it mentions the POST method and parameter types, but lacks details on permissions, rate limits, or what happens on partial updates. With annotations covering safety and idempotency, the description adds some value but is not rich in behavioral disclosure.

  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 brief and front-loaded with the tool name and method, but includes redundant information (e.g., repeating parameter details that are in the schema) and lacks efficient structuring. Sentences like 'Parameters: - name (string, optional)' are verbose for listing types without added value, making it somewhat bloated despite its short length.

  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 has no output schema, annotations provide safety hints but not full behavioral context. The description lacks details on return values, error conditions, or operational constraints (e.g., authentication needs). For a mutation tool with 4 parameters and 0% schema coverage, this description is incomplete, leaving gaps in understanding how to use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types (e.g., 'name (string, optional)'), but doesn't explain their meanings, constraints (e.g., minLength for name), or formats (e.g., date format for lastUsedAt). It partially compensates by identifying required vs. optional parameters, but fails to add sufficient semantic context beyond what's inferable from the schema structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool updates an SSH key with specific parameters (name, description, lastUsedAt, sshKeyId), which is a clear verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'dokploy_sshKey_create' or 'dokploy_sshKey_remove', leaving ambiguity about when to use update versus other SSH key operations.

  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 is provided on when to use this tool versus alternatives. The description lists parameters but doesn't mention prerequisites (e.g., needing an existing SSH key ID), exclusions, or comparisons to sibling tools like 'dokploy_sshKey_create' for new keys or 'dokploy_sshKey_remove' for deletion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_getUserByTokenC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying it's a GET operation, which aligns with annotations but doesn't provide additional details like authentication requirements, rate limits, or error conditions. No contradiction with annotations exists.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) and a parameter list that adds little beyond the schema. While not verbose, it lacks efficient information density, with the parameter section being minimally useful given the schema already defines it.

  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 purpose (user retrieval by token), no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what the tool returns (e.g., user object details), error handling, or how it fits into broader workflows. Annotations provide safety hints, but the description fails to add necessary operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists the 'token' parameter as required but provides no semantic context—what the token represents, its format, how to obtain it, or validation rules. This leaves the parameter meaning unclear beyond the basic schema type, failing to add meaningful value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves a user by token, which is a clear purpose with a specific verb ('get') and resource ('user'). However, it doesn't differentiate from sibling tools like 'dokploy_user_get' or 'dokploy_user_one', leaving ambiguity about when to use this specific token-based lookup versus other user retrieval methods.

  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 is provided on when to use this tool versus alternatives. The description lists parameters but offers no context about prerequisites (e.g., token source), typical use cases, or comparisons to sibling tools like 'dokploy_user_get' or 'dokploy_user_one'. This leaves the agent without direction on appropriate usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_volumeBackups_oneC
  2.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover key behavioral traits: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable read operation. The description adds minimal value by specifying 'GET', which aligns with annotations but does not provide additional context (e.g., error handling, rate limits, or response format). No contradiction exists, so the score reflects moderate added value beyond annotations.

  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 and front-loaded with the tool name and HTTP method, but it includes a redundant 'Parameters:' section that partially repeats schema information. While efficient in length, the structure could be improved by integrating parameter details more seamlessly or omitting them since they are in the schema.

  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 a retrieval tool with no output schema and 0% schema description coverage, the description is inadequate. It lacks details on what the tool returns (e.g., backup metadata), error conditions, or how it interacts with sibling tools. Annotations help, but the description does not compensate for the missing output schema, making it incomplete for effective agent use.

  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 0%, and the description lists 'volumeBackupId (string, required)' under 'Parameters:', which adds basic semantics (parameter name, type, and requirement). However, it does not explain what a volumeBackupId is, its format, or where to obtain it, leaving gaps. With one parameter and no schema descriptions, the baseline is 3 as the description provides some but incomplete parameter information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[volumeBackups] volumeBackups.one (GET)' is tautological, essentially restating the tool name and title with minimal context. It mentions 'GET' which implies retrieval, but lacks a specific verb-resource combination (e.g., 'Retrieve a specific volume backup by ID') and does not differentiate from sibling tools like 'dokploy_volumeBackups_list' or 'dokploy_volumeBackups_create', leaving the purpose vague.

  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 is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context (e.g., after listing backups), or exclusions. With siblings like 'dokploy_volumeBackups_list' and 'dokploy_volumeBackups_create', the absence of usage guidelines makes it unclear how this tool fits into workflows.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_markRunningC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, non-idempotent, open-world operation. The description adds minimal behavioral context by specifying it's a POST request, which aligns with the mutable nature. However, it doesn't disclose critical details like what 'markRunning' entails (e.g., side effects, permissions needed, or response format), leaving gaps despite annotations covering basic safety.

  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 brief and front-loaded with the tool signature, but includes redundant formatting (brackets, parentheses) and a parameter list that adds little value. While efficient, it could be more polished by integrating the parameter info into a cohesive sentence, though it avoids unnecessary verbosity.

  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 (a mutable operation with no output schema and 0% parameter coverage), the description is inadequate. It lacks details on what 'markRunning' does, expected outcomes, error conditions, or how it interacts with other application states. Annotations provide some safety context, but the description doesn't fill the gaps for effective agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, with one required parameter (applicationId). The description only lists 'applicationId (string, required)' without explaining what this ID represents (e.g., format, source, or constraints). It fails to compensate for the lack of schema descriptions, providing no meaningful semantics beyond what the bare schema already indicates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool is 'application.markRunning (POST)' which implies it marks an application as running via a POST request. However, it doesn't specify what 'markRunning' means operationally (e.g., sets status, triggers process) or how it differs from sibling tools like 'dokploy_application_start' or 'dokploy_application_deploy'. The purpose is vague beyond the basic verb+resource.

  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 is provided on when to use this tool versus alternatives. With many sibling tools for application management (start, stop, deploy, redeploy), the description offers no context about prerequisites, appropriate scenarios, or exclusions. The agent must infer usage from the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_moveC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, implying a state-changing action, but doesn't provide additional behavioral context beyond what annotations already cover (e.g., whether it requires specific permissions, what happens to the application during the move, or if it's asynchronous). No contradiction with annotations exists.

  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 brief and front-loaded with the tool name and HTTP method, but the parameter list is redundant with the schema and lacks explanatory value. It could be more efficient by omitting the parameter enumeration or adding meaningful context instead.

  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 moving an application (a state-changing operation), the description is inadequate. With no output schema, it doesn't explain return values or success/failure indicators. Combined with 0% schema coverage and minimal behavioral details, it leaves too many unknowns for reliable use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists the two parameters (applicationId and targetEnvironmentId) but provides no semantic meaning—what an 'applicationId' refers to, what a 'targetEnvironmentId' represents, or how to obtain valid values. This leaves critical gaps for proper tool invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool moves an application, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like dokploy_application_deploy, dokploy_application_redeploy, or dokploy_compose_move, leaving ambiguity about what 'move' specifically entails versus deployment operations.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the application must be stopped first), what 'move' means in context (e.g., between environments, servers, or clusters), or when not to use it (e.g., during active deployments).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_manualBackupComposeC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, which aligns with the annotations (non-read-only). However, it doesn't disclose additional behavioral traits such as what 'manual' implies (e.g., user-triggered vs automated), potential side effects (e.g., system load during backup), or error conditions. The description doesn't contradict annotations but adds minimal context beyond them.

  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 brief and structured with a clear header and parameter list, avoiding unnecessary words. However, it could be more front-loaded by starting with a concise purpose statement instead of the bracketed '[backup]'. The two-line format is efficient but slightly awkward in presentation.

  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 (a backup operation with potential side effects), annotations provide some behavioral hints, but there's no output schema. The description lacks details on what the tool returns (e.g., success status, backup file location), error handling, or dependencies. For a manual backup tool in a system with many siblings, this leaves significant gaps in understanding how to use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'backupId' as a required string parameter, but schema description coverage is 0%, so the schema provides no details. The description doesn't add meaning beyond the parameter name—it doesn't explain what a backupId is, how to obtain it, or its format (e.g., UUID, numeric ID). For a single parameter with no schema documentation, this is insufficient to guide proper usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool performs a backup operation ('backup.manualBackupCompose') and mentions it's a POST request, which implies creation/initiation. However, it doesn't specify what 'Compose' refers to (likely Docker Compose configurations) or differentiate it from similar backup tools like 'manualBackupMariadb' or 'manualBackupWebServer' in the sibling list. The purpose is somewhat clear but lacks specificity about the resource being backed up.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing backup configurations), timing considerations, or compare it to other backup-related tools in the sibling list (e.g., 'dokploy_backup_create', 'dokploy_backup_listBackupFiles'). Usage is implied by the name but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_manualBackupMariadbC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description doesn't add meaningful behavioral context beyond that. It mentions 'POST' and parameters, which are already implied by the schema, but fails to disclose details like backup location, permissions needed, or potential side effects, leaving gaps despite annotations.

  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 brief and front-loaded with the tool name and HTTP method, but it includes a redundant parameter list that adds little value. Overall, it's efficient but could be more structured by integrating key details into a cohesive sentence.

  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 a backup operation, no output schema, and low parameter coverage, the description is incomplete. It lacks information on what the tool returns, error conditions, or prerequisites, making it inadequate for safe and effective use by an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'backupId' as a required string parameter without explaining what it represents (e.g., an existing backup identifier or a new backup name). This adds minimal semantics beyond the schema, insufficient to compensate for the low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool performs a 'manual backup' for MariaDB, which is a specific verb and resource. However, it doesn't distinguish this from sibling backup tools like 'manualBackupCompose' or 'manualBackupPostgres' beyond the database type, leaving the purpose somewhat vague regarding what exactly gets backed up or how it differs.

  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, such as automated backups or other database backup tools in the sibling list. The description only lists parameters without context, so the agent lacks explicit or implied usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_manualBackupMySqlC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a 'manual' backup, implying user-initiated action rather than automated, which provides context beyond annotations. However, it doesn't detail side effects, permissions needed, or rate limits, leaving behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the tool's purpose, though it includes redundant formatting like brackets and HTTP method. It wastes no words but could be more polished by removing extraneous details. Overall, it's efficient but not perfectly structured.

  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 has no output schema and annotations only cover basic hints, the description is incomplete. It doesn't explain what the backup entails, how to verify success, or what the response looks like. For a backup operation with potential side effects, more context is needed to guide the agent effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only indicates 'backupId' is a required string. The description lists the parameter but adds no meaning—it doesn't explain what a backupId is, how to obtain it, or its format. This fails to compensate for the low schema coverage, offering minimal value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool performs a manual backup of MySQL, which is a specific verb+resource combination. However, it doesn't differentiate from sibling backup tools like 'manualBackupPostgres' or 'manualBackupMariadb' beyond the MySQL specificity. The purpose is clear but lacks sibling distinction.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, timing, or compare it to other backup methods (e.g., automated backups or other database types). Usage is implied by the name but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_manualBackupWebServerC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds no behavioral context beyond that. It mentions 'POST' and 'backup', implying a write action, which aligns with readOnlyHint=false, but doesn't clarify effects like whether it triggers an immediate backup, requires specific permissions, or has rate limits. With annotations covering basic traits, the description adds minimal value.

  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 brief and structured with a clear header and parameter list, avoiding unnecessary fluff. However, it could be more front-loaded by stating the purpose upfront rather than embedding it in brackets, and the parameter explanation is overly terse given the lack of schema coverage.

  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 (a write operation with no output schema and 0% parameter coverage), the description is inadequate. It doesn't explain the outcome, error conditions, or how this fits into the broader backup system, leaving significant gaps for the agent to navigate without additional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'backupId (string, required)' without explaining what a backupId is, how to obtain it, or its format. With one undocumented parameter, the description fails to compensate for the schema's lack of details, leaving the agent guessing about input semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool performs a 'manual backup' for a 'web server', which clarifies the verb and resource. However, it doesn't differentiate from sibling backup tools (e.g., manualBackupCompose, manualBackupMariadb) beyond specifying 'web server', leaving ambiguity about what exactly is being backed up. The purpose is clear but lacks specificity compared to alternatives.

  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 is provided on when to use this tool versus other backup tools (e.g., manualBackupCompose, manualBackupMariadb) or automated backups. The description only lists parameters without context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_bitbucket_getBitbucketBranchesC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate read-only, non-destructive, idempotent, and open-world behavior, which the description doesn't contradict. However, it adds minimal context beyond the HTTP method (GET) and parameter list, failing to detail aspects like rate limits, authentication needs, or pagination. With annotations covering safety, the description provides basic but insufficient behavioral insight.

  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 brief and front-loaded with the tool name and HTTP method, followed by a parameter list. It avoids redundancy but is overly terse, missing explanatory context. The structure is clear but could be more informative without sacrificing conciseness.

  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 (3 parameters, 0% schema coverage, no output schema), the description is inadequate. It lacks details on return values, error handling, authentication, or how it integrates with other Bitbucket tools. Annotations provide safety hints, but the description fails to complete the contextual picture for effective agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (owner, repo, bitbucketId) and their types/requirements, but adds no semantic meaning—e.g., what 'owner' refers to (username, organization), how 'bitbucketId' is used, or format examples. This leaves parameters under-specified despite the low schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves Bitbucket branches (verb+resource) but lacks specificity about scope or format. It doesn't distinguish from sibling tools like dokploy_gitea_getGiteaBranches or dokploy_github_getGithubBranches beyond the Bitbucket context. The purpose is clear but generic.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, such as needing a configured Bitbucket provider, or differentiate it from other branch-fetching tools in the sibling list. Usage is implied by the parameter list but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_bitbucket_getBitbucketRepositoriesC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover safety (readOnlyHint=true, destructiveHint=false) and idempotency, so the description doesn't need to repeat these. It adds minimal value by implying a GET operation and listing the parameter, but fails to disclose behavioral traits like pagination, error handling, or authentication needs beyond what annotations provide.

  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 brief and front-loaded with the tool name and HTTP method, avoiding unnecessary details. However, the parameter listing is redundant with the schema and could be omitted for better efficiency, slightly reducing its score.

  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 (retrieving repositories), lack of output schema, and 0% schema description coverage, the description is insufficient. It misses key details like the return format, error conditions, and how results are structured, leaving the agent with incomplete information for proper use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists the parameter 'bitbucketId' but provides no semantic context—what this ID represents, where to find it, or its format. This leaves the parameter meaning unclear despite the schema defining its type and constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves Bitbucket repositories, which is a clear verb+resource combination. However, it doesn't specify what 'get' means (list? fetch details?) or differentiate from sibling tools like dokploy_bitbucket_bitbucketProviders or dokploy_bitbucket_getBitbucketBranches, leaving the scope vague.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing a configured Bitbucket provider) or comparisons to similar tools like dokploy_gitea_getGiteaRepositories, offering no usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_deployment_allByServerC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints (readOnly, non-destructive, idempotent, openWorld), so the description's burden is lower. It adds minimal context by specifying the HTTP method (GET) and implying server-scoped filtering, but doesn't describe response format, pagination, error conditions, or authentication needs. No contradiction with annotations exists.

  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 brief and front-loaded with the core action, avoiding unnecessary elaboration. However, the formatting with brackets and parentheses ('[deployment] deployment.allByServer (GET)') is slightly cluttered, and the parameter listing is minimal but not wasteful.

  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 purpose (listing deployments by server), the description is incomplete. It lacks output details (no schema provided), doesn't clarify the relationship to sibling deployment tools, and omits parameter semantics. While annotations cover safety, the description fails to provide sufficient context for effective use in a complex deployment management system.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists the parameter name ('serverId') without explaining what a serverId is, its format, or where to obtain it. This leaves the parameter's meaning and usage ambiguous, failing to add meaningful semantics beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves deployments by server ('deployment.allByServer (GET)'), which is a clear verb+resource combination. However, it doesn't distinguish this from sibling deployment tools like 'dokploy_deployment_all', 'dokploy_deployment_allByCompose', or 'dokploy_deployment_allByType', leaving the agent to infer differences from naming alone.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for selecting this over other deployment listing tools, or any exclusions. The agent must rely solely on the tool name to guess usage scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_destination_createC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description doesn't contradict these, but adds minimal behavioral context beyond the parameter list. It lacks details on authentication needs, rate limits, or what 'destination' entails, though annotations cover basic safety.

  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 and front-loaded with the tool name and HTTP method. The parameter list is structured but could be more integrated. It avoids unnecessary verbosity, though the parameter details might be better in the schema.

  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 with 0% schema coverage, no output schema, and annotations only covering basic hints, the description is incomplete. It doesn't explain what a destination is, how it's used, or the return value, leaving significant gaps for a creation tool in a complex system.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters with types and required status, but adds no meaning beyond what the schema already provides (e.g., no explanation of 'provider' options, 'endpoint' format, or 'serverId' context). This fails to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool creates a destination, which is a specific verb+resource, but it's vague about what a 'destination' represents in the Dokploy context. It doesn't differentiate from sibling tools like dokploy_destination_update or dokploy_destination_remove, leaving the purpose unclear beyond basic creation.

  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 lists parameters but doesn't mention prerequisites, context, or exclusions. Sibling tools like dokploy_destination_update and dokploy_destination_remove exist, but no comparison is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_docker_getContainersC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide strong hints (readOnly, non-destructive, idempotent, open-world), so the description's burden is lower. It adds minimal behavioral context by implying a GET operation, but doesn't detail output format, pagination, error handling, or serverId implications. No contradiction with annotations exists, but the description adds little beyond them.

  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 brief and front-loaded with the core action ('docker.getContainers (GET)'), avoiding unnecessary words. However, the parameter listing is minimal and could be more integrated. It's efficient but slightly under-specified rather than overly concise.

  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 1 parameter with 0% schema coverage, no output schema, and annotations covering safety but not operational details, the description is incomplete. It lacks information on return values, error cases, and serverId usage, making it inadequate for reliable tool invocation in a complex Docker management context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists 'serverId (string, optional)' without explaining what serverId refers to, its format, or when it's needed. This fails to add meaningful semantics beyond the bare schema, leaving the parameter poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves Docker containers, which is a clear verb+resource combination. However, it doesn't specify what 'getContainers' means in practice (e.g., list, fetch details) or differentiate it from similar sibling tools like 'dokploy_docker_getContainersByAppLabel' or 'dokploy_docker_getServiceContainersByAppName'. The purpose is understandable but lacks specificity.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., server selection), or exclusions. With many sibling Docker container tools, this omission leaves the agent without direction on tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_docker_getStackContainersByAppNameC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide strong behavioral hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds minimal context by specifying it's a GET operation, but doesn't disclose additional traits like rate limits, authentication needs, or what 'stack containers' entails. It doesn't contradict annotations, but adds little beyond them.

  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 and front-loaded with the tool name and HTTP method, followed by a parameter list. It avoids unnecessary fluff, but the parameter section could be more integrated into the purpose statement for better flow. Overall, it's efficient but not perfectly structured.

  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 (Docker container retrieval), lack of output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'stack containers' are, the return format, or error conditions. Annotations help with safety, but the description fails to provide enough context for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (appName, serverId) and their types/requirements, but adds no semantic meaning—no explanation of what 'appName' refers to, what 'serverId' is used for, or format examples. This fails to address the coverage gap, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves Docker stack containers by app name, which is a clear purpose with a specific verb ('get') and resource ('stack containers'). However, it doesn't distinguish this from sibling Docker container tools like 'dokploy_docker_getContainers' or 'dokploy_docker_getContainersByAppLabel', leaving ambiguity about when to use this specific tool versus others.

  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 is provided on when to use this tool versus alternatives. The description only lists parameters without explaining context, prerequisites, or how it differs from similar Docker container retrieval tools in the sibling list. This leaves the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitea_getGiteaRepositoriesC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate it's read-only, non-destructive, idempotent, and open-world, so the description doesn't need to repeat these. However, it adds minimal context by specifying it's a GET operation, which implies safe retrieval, but fails to disclose potential behaviors like pagination, error handling, or rate limits that could affect usage.

  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 and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) that adds noise. The parameter listing is minimal, making it efficient, though it could be structured more clearly without sacrificing brevity.

  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 (retrieving repositories), lack of output schema, and low schema coverage, the description is incomplete. It doesn't explain what the output contains (e.g., list of repositories, metadata) or any constraints, leaving gaps for an AI agent to understand the full context of use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists 'giteaId' as a required string without explaining its meaning (e.g., an identifier for a Gitea provider instance). This leaves the parameter's purpose unclear, failing to add meaningful semantics beyond the basic schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves Gitea repositories, which is a clear purpose, but it's vague about scope (e.g., all repositories for a Gitea instance vs. filtered). It doesn't differentiate from sibling tools like 'dokploy_gitea_getGiteaBranches' or 'dokploy_github_getGithubRepositories', leaving ambiguity about when to use each.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing a valid Gitea ID) or comparisons to sibling tools, such as 'dokploy_gitea_getGiteaBranches' for branches or 'dokploy_github_getGithubRepositories' for GitHub repositories.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_github_getGithubRepositoriesC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is read-only, non-destructive, idempotent, and open-world, covering key behavioral traits. The description adds minimal context by noting it's a GET operation, which aligns with read-only behavior but doesn't provide additional details like rate limits, authentication needs, or pagination. Since annotations handle the core safety profile, the description's limited addition justifies a baseline score.

  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 brief and structured with a clear header ('[github] github.getGithubRepositories (GET)') and a parameters section. It avoids unnecessary words, but the lack of explanatory content for the parameter reduces its effectiveness. Overall, it's efficiently formatted but under-specified.

  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 has no output schema and low schema description coverage (0%), the description is insufficient. It doesn't explain what the tool returns (e.g., list of repositories, error formats) or provide context on the 'githubId' parameter. Annotations help with behavioral aspects, but the description leaves too many gaps for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description only lists 'githubId' as a required string without explaining its meaning (e.g., GitHub username, organization ID, or provider identifier). This fails to compensate for the schema's lack of documentation, leaving the parameter's purpose unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves GitHub repositories ('getGithubRepositories') and mentions it's a GET operation, which clarifies the action. However, it doesn't specify what 'githubId' refers to (e.g., a user, organization, or token) or the scope of repositories returned (e.g., all, public only, owned by the ID). This leaves the purpose somewhat vague compared to what a fully clear description would provide.

  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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'dokploy_github_getGithubBranches' or 'dokploy_bitbucket_getBitbucketRepositories', nor does it specify prerequisites (e.g., needing a configured GitHub provider). Without this, an agent lacks context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitlab_getGitlabRepositoriesC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds minimal behavioral context by specifying it's a GET operation, but doesn't describe what 'gitlabId' represents, whether this returns all repositories or a filtered subset, or any pagination/rate limiting considerations.

  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 extremely concise - just two lines showing the tool name and parameter. While this is efficient, it borders on under-specification. The structure is clear but lacks the explanatory content needed for effective tool selection.

  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?

  For a tool with 0% schema description coverage, no output schema, and no explanation of what 'gitlabId' means, the description is insufficient. While annotations provide safety information, the description fails to explain the tool's purpose in context, what it returns, or how to properly use the single required parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no documentation about the 'gitlabId' parameter. The description merely lists the parameter name without explaining what it represents (e.g., GitLab instance ID, user ID, project ID), what format it expects, or where to obtain it. This leaves a critical gap in understanding how to use the tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves GitLab repositories, which is a clear verb+resource combination. However, it doesn't distinguish this tool from similar sibling tools like 'dokploy_gitlab_getGitlabBranches' or 'dokploy_github_getGithubRepositories' - it merely repeats the tool name with minimal context.

  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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate, or what distinguishes it from other repository-fetching tools in the sibling list (like GitHub or Bitbucket equivalents).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_stopC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is not read-only, not destructive, not idempotent, and open-world. The description adds minimal behavioral context beyond annotations—it specifies the HTTP method (POST) but doesn't explain what 'stop' entails (e.g., graceful shutdown, service interruption, or effects on connected applications). With annotations covering safety aspects, the description provides limited additional value.

  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 brief and front-loaded with the tool name and HTTP method, but includes a redundant parameter list that adds little value. It avoids unnecessary verbosity, though it could be more structured (e.g., separating purpose from parameters).

  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 (a state-changing operation), lack of output schema, and low schema coverage, the description is incomplete. It doesn't explain the outcome of stopping MariaDB, potential side effects, error conditions, or how to verify success, leaving significant gaps for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'mariadbId' as a required parameter but provides no semantic meaning (e.g., what this ID represents, where to find it, or format examples). This leaves the parameter poorly understood despite the low schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool stops a MariaDB instance ('mariadb.stop'), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'dokploy_mariadb_start' or 'dokploy_mariadb_changeStatus', leaving the purpose somewhat vague regarding how it relates to other status management tools.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., the MariaDB must be running), when not to use it, or refer to sibling tools like 'start' or 'changeStatus' for context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_testDiscordConnectionC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate the tool is non-read-only, non-destructive, non-idempotent, and open-world, but the description adds minimal behavioral context. It mentions it's a POST request, implying a mutation that may send data, but doesn't detail effects like whether it sends a test message, logs results, or requires specific permissions. With annotations covering safety basics, the description provides some value but lacks rich behavioral disclosure.

  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 and front-loaded with the tool name and HTTP method, followed by a parameter list. It avoids unnecessary fluff, but the parameter list lacks explanatory text, making it somewhat sparse. Overall, it's efficiently structured but could be more informative without losing brevity.

  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 has 2 parameters with 0% schema coverage, no output schema, and annotations that only cover basic hints, the description is incomplete. It doesn't explain what the tool returns (e.g., success status, error messages), how 'decoration' affects the test, or the expected outcome of testing the connection. For a mutation tool with undocumented parameters, this leaves significant gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter details. The description lists parameters 'webhookUrl' and 'decoration' but doesn't explain their semantics—what a webhookUrl should be (e.g., Discord webhook URL format), what 'decoration' does (e.g., adds formatting to the test message), or examples. It fails to compensate for the low schema coverage, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool is for testing a Discord connection via a notification, which provides a basic purpose. However, it's vague about what 'test' entails (e.g., sending a test message, validating webhook) and doesn't distinguish from sibling notification test tools like 'testEmailConnection' or 'testSlackConnection', leaving ambiguity about its specific function.

  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 is provided on when to use this tool versus alternatives. The description lacks context such as prerequisites (e.g., needing a configured Discord notification first), typical scenarios (e.g., after setting up a Discord notification), or comparisons to other test tools in the sibling list, leaving the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_testTeamsConnectionC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request for testing, implying it may send data to the webhook, which aligns with annotations. However, it doesn't disclose additional behavioral traits like expected response format, error conditions, or rate limits, leaving gaps beyond the annotations.

  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 brief and front-loaded with the tool's purpose, but includes redundant formatting (brackets and parentheses) that doesn't add value. It efficiently states the action and parameter, though it could be more polished.

  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 has no output schema and annotations only cover basic hints, the description is incomplete. It doesn't explain what a successful test entails (e.g., returns a status message), error handling, or how it integrates with other notification tools, making it inadequate for informed use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists the parameter name and type without adding meaning. It doesn't explain what the webhookUrl should be (e.g., a Microsoft Teams webhook URL format), its purpose in the test, or validation rules, failing to compensate for the low schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool tests a Teams connection for notifications, which is a specific verb+resource. However, it doesn't distinguish from sibling tools like other testConnection tools (e.g., testDiscordConnection, testSlackConnection) beyond the Teams-specific mention, leaving the purpose somewhat vague in comparison.

  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 is provided on when to use this tool versus alternatives. The description lacks context on prerequisites, such as whether a Teams notification must be configured first, or when testing is needed (e.g., after setup or troubleshooting).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_updateC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-destructive, idempotent, open-world mutation tool (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds minimal context by specifying it's a POST operation and listing parameters, but doesn't elaborate on behavioral aspects like permission requirements, rate limits, or what happens to unspecified fields during update. It doesn't contradict annotations, so no penalty.

  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 brief and front-loaded with the tool name and HTTP method, followed by a parameter list. It avoids unnecessary fluff, but the parameter list could be integrated more smoothly into a sentence for better flow.

  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 has 3 parameters with 0% schema coverage, no output schema, and annotations that don't cover all behavioral aspects (e.g., auth needs), the description is incomplete. It lacks details on return values, error conditions, and deeper parameter semantics, making it insufficient for safe and effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (organizationId, name, logo) with types and required/optional status, which adds some meaning beyond the bare schema. However, it doesn't explain what these parameters represent (e.g., organizationId format, logo as URL or base64, name constraints), leaving significant gaps in understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool updates an organization with specific parameters (name, logo), which is a clear verb+resource. However, it doesn't distinguish this from sibling tools like 'dokploy_organization_create' or 'dokploy_organization_delete', leaving the scope vague regarding what 'update' entails compared to creation or deletion.

  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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing organization), exclusions, or compare it to related tools like 'dokploy_organization_create' for initial setup or 'dokploy_organization_delete' for removal.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_patch_readRepoFileC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive safety information (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds minimal behavioral context - it mentions it's a GET operation (implied read-only) and lists parameters, but doesn't describe what happens when the file doesn't exist, authentication requirements, rate limits, or return format. With good annotations, this earns a baseline 3 for providing the HTTP method 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 extremely concise - just the HTTP method and parameter listing. It's front-loaded with the most important information (patch.readRepoFile GET). While perhaps too minimal, every element serves a purpose with zero wasted words. The structure is clear though basic.

  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 3 parameters with 0% schema coverage, no output schema, and annotations that only cover safety aspects, the description is incomplete. It doesn't explain what the tool returns (file content? metadata?), what happens on errors, or provide any domain context about 'patch' repositories. For a file-reading tool in a complex deployment system, this leaves significant gaps for an agent to understand proper usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning none of the parameters have descriptions in the schema. The description lists parameter names and types but provides no semantic meaning: what 'id' refers to (repository ID? patch ID?), what 'type' of 'application' or 'compose' means, or what 'filePath' represents. For 3 undocumented parameters, this minimal listing doesn't adequately compensate for the schema gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool reads a file from a repository, which is a clear verb+resource combination. However, it doesn't specify what kind of repository (patch repository) or provide any context about what 'patch' refers to in this system. The description is functional but lacks domain-specific clarity that would help distinguish it from other file-reading tools.

  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 guidance on when to use this tool versus alternatives. There are many sibling tools (like dokploy_patch_readRepoDirectories, dokploy_patch_one, dokploy_application_readAppMonitoring) that might be related, but no indication is given about when this specific file-reading tool is appropriate versus other read operations in the system.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_saveExternalPortC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, but the description adds minimal behavioral context. It implies a write action ('save') without specifying effects like whether it overrides existing ports, requires specific permissions, or has rate limits. The description doesn't contradict annotations but provides little extra insight beyond the structured hints.

  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 and front-loaded with the tool name and method, but it includes a redundant parameter list that adds little value. While efficient in length, the structure could be improved by integrating meaningful context instead of just repeating parameter names, though it avoids unnecessary verbosity.

  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 a write operation with no output schema and low schema coverage, the description is inadequate. It fails to explain the tool's purpose in detail, parameter meanings, behavioral traits, or expected outcomes, leaving the agent with insufficient information to use the tool effectively in context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists parameter names without explaining their semantics. It mentions 'postgresId' and 'externalPort' but doesn't clarify what these represent (e.g., ID format, port number constraints, or that 'externalPort' can be null). This leaves significant gaps in understanding parameter usage beyond the basic schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool is for 'postgres.saveExternalPort' with a POST method, indicating it saves an external port for a PostgreSQL resource. However, it's vague about what 'save' entails (e.g., setting, updating, or configuring a port) and doesn't differentiate from sibling tools like 'dokploy_postgres_saveEnvironment', leaving ambiguity in its specific function.

  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 is provided on when to use this tool versus alternatives. It lacks context such as prerequisites (e.g., needing an existing PostgreSQL instance), when to choose this over other 'saveExternalPort' tools for different databases (e.g., mariadb, mongo), or any exclusions, making it unclear in the broader toolset.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_project_createC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request for creation, which aligns with annotations but doesn't provide extra behavioral context like error handling, permissions needed, or rate limits. No contradiction with annotations exists.

  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 front-loaded with the action and parameters in a clear, bullet-point format. It avoids unnecessary fluff, though it could be more structured by separating usage notes from parameter lists. Every sentence serves a purpose, making it efficient.

  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 (creation tool with 3 parameters), no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the return value, error cases, or how the tool fits into the broader system (e.g., project lifecycle). Annotations help but don't fully compensate for these gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (name, description, env) with basic types but lacks semantic details such as format constraints (e.g., name uniqueness), purpose of 'env', or examples. This adds minimal value beyond the schema's structural info.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool creates a project with specific parameters (name, description, env), which clarifies the verb and resource. However, it doesn't distinguish this from sibling tools like 'dokploy_project_update' or 'dokploy_project_duplicate', leaving the scope vague regarding when to create versus update or duplicate.

  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 is provided on when to use this tool versus alternatives. The description lists parameters but doesn't mention prerequisites, context (e.g., initial setup vs. adding projects), or when to choose this over similar tools like 'dokploy_project_update' or 'dokploy_project_duplicate'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_security_deleteC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying deletion. However, the description adds minimal behavioral context beyond annotations—it doesn't specify consequences (e.g., irreversible removal), permissions required, or error handling. With annotations covering safety, it meets a baseline 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the tool name and HTTP method, avoiding unnecessary fluff. However, the formatting with brackets and 'Parameters:' is slightly cluttered, and it could be more polished without sacrificing clarity.

  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 destructive nature (annotations hint at this), no output schema, and low parameter coverage, the description is insufficient. It doesn't explain what happens post-deletion, potential side effects, or return values, leaving gaps for a mutation tool in a complex system with many siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists the securityId parameter but provides no semantic details—what a securityId is, how to obtain it, or format examples. This leaves the parameter poorly explained, failing to add meaningful value beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool deletes a security entity ('security.delete') and mentions the required securityId parameter, which clarifies the verb and resource. However, it doesn't specify what type of security entity (e.g., user, role, policy) or distinguish it from other delete operations like dokploy_ai_delete or dokploy_application_delete, making it somewhat vague.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing to identify a security entity first, or references to sibling tools like dokploy_security_create or dokploy_security_update for related operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_createC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation, which the description does not contradict. However, the description adds minimal behavioral context beyond the parameter list, such as what happens upon creation (e.g., server initialization, potential side effects). With annotations covering basic traits, the description provides limited additional value.

  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 structured with a clear header and bullet-pointed parameters, making it easy to scan. It avoids unnecessary fluff, though it could be more front-loaded with a summary sentence before the parameter list.

  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 creating a server with 7 required parameters, 0% schema description coverage, no output schema, and annotations that only cover basic hints, the description is incomplete. It fails to explain the outcome, error conditions, or integration with other tools, leaving the agent with insufficient context for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 by explaining parameters. It lists parameters with types and requirements but does not add meaning beyond the schema (e.g., what 'serverType' entails, format constraints for 'ipAddress' or 'sshKeyId'). This leaves significant gaps in understanding parameter usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool creates a server with a list of parameters, which clarifies the verb (create) and resource (server). However, it does not differentiate from sibling tools like 'dokploy_server_update' or 'dokploy_server_setup', making the purpose somewhat vague in context.

  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 is provided on when to use this tool versus alternatives such as updating existing servers or other server-related tools. The description lacks context about prerequisites, dependencies, or typical scenarios for server creation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_getServerTimeC
  2.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description doesn't contradict the annotations (which indicate read-only, non-destructive, idempotent, and open-world behavior). While the annotations already provide comprehensive behavioral information, the description adds minimal context by specifying the HTTP method (GET), which provides some implementation detail. However, it doesn't describe what format the time is returned in or any other behavioral aspects.

  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 extremely concise (just 4 words), but this brevity comes at the cost of being under-specified rather than efficiently informative. While there's no wasted text, the description fails to provide meaningful information that would help an agent understand the tool's purpose and usage.

  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 that this is a simple read-only tool with comprehensive annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) and no parameters, the description is minimally adequate. However, without an output schema, the description should ideally specify what format the server time is returned in (e.g., timestamp, ISO string). The current description leaves this ambiguous.

  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 parameters and 100% schema description coverage, the baseline score would be 4 even with no parameter information in the description. The description doesn't add any parameter semantics (since there are no parameters), but this is appropriate given the complete schema coverage and parameter count.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[server] server.getServerTime (GET)' is a tautology that restates the name/title with minimal additional information. While it implies retrieving server time, it lacks a specific verb-resource combination and doesn't distinguish this tool from any siblings. The description provides no meaningful elaboration beyond what's already in the tool name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparison with sibling tools. Given the extensive list of sibling tools, this lack of differentiation leaves the agent with no usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_getTraefikPortsC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a read-only, non-destructive, idempotent, and open-world operation. The description adds minimal behavioral context by specifying it's a GET request, which aligns with read-only behavior. However, it doesn't disclose additional traits like rate limits, authentication needs, or what 'Traefik ports' specifically refers to (e.g., dashboard ports, entry points).

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant brackets and formatting that add noise. The parameter listing is minimal, making it efficient overall, though it could be cleaner.

  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 a system tool with no output schema and low parameter documentation, the description is inadequate. It doesn't explain what 'Traefik ports' are, the return format, or error conditions. Annotations provide safety hints, but more context is needed for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists the parameter 'serverId' as optional without explaining its purpose, format, or when it should be used. This fails to compensate for the lack of schema documentation, leaving the parameter's meaning unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves Traefik ports from settings, which is a specific verb (get) and resource (Traefik ports). However, it doesn't distinguish this from sibling tools like 'dokploy_settings_readTraefikConfig' or 'dokploy_settings_updateTraefikPorts', leaving the scope unclear. The purpose is identifiable but lacks differentiation.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions. With many sibling tools related to Traefik configuration, this omission leaves the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_saveSSHPrivateKeyC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, open-world operation. The description adds that this is a POST request, implying a write operation, which aligns with annotations. However, it doesn't provide additional behavioral context like authentication requirements, rate limits, or what 'save' entails (e.g., overwriting existing keys, validation). With annotations covering basic traits, the description adds minimal extra value.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant brackets and formatting (e.g., '[settings]') that don't add value. It efficiently states the action but could be cleaner without the extra markup.

  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 saving sensitive SSH keys, the lack of output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain the outcome (e.g., success response, error handling), security implications, or how this integrates with other tools. For a mutation tool with no output schema, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 only lists the parameter name 'sshPrivateKey' without explaining its format (e.g., PEM format, passphrase handling), purpose, or constraints. This leaves critical semantics undocumented, failing to bridge the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool saves an SSH private key, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'dokploy_sshKey_create' or 'dokploy_settings_cleanSSHPrivateKey', leaving ambiguity about how this differs from other SSH key management operations.

  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 is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., whether this is for system-wide settings vs. user-specific keys), or what happens after saving. Without this, an agent cannot make informed decisions about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateDockerCleanupC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a non-read-only, potentially destructive operation. The description adds no behavioral context beyond this, such as what 'destructive' entails (e.g., data loss, system impact) or any rate limits. It doesn't contradict annotations, but provides minimal additional value.

  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 brief and front-loaded with the tool name and HTTP method, followed by a parameter list. It avoids unnecessary words, but the parameter details are minimal and could be more informative without sacrificing conciseness.

  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 destructive annotations, 0% schema coverage, no output schema, and a mutation tool, the description is incomplete. It lacks details on what the tool returns, error conditions, or the effect of enabling/disabling cleanup, making it insufficient for safe and effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters with types but no semantics—e.g., what 'enableDockerCleanup' does or when 'serverId' is needed. This adds little meaning beyond the schema, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool updates Docker cleanup settings, which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'dokploy_settings_cleanDockerPrune' or 'dokploy_settings_cleanUnusedImages' that also relate to Docker cleanup, leaving the exact scope unclear.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as server selection, and doesn't mention any sibling tools for comparison, leaving usage decisions ambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateTraefikPortsC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-destructive, idempotent, open-world mutation tool (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description doesn't contradict these but adds minimal behavioral context—it specifies it's a POST operation, implying a write, but doesn't detail effects like whether ports are appended or replaced, or if changes require server reloads. With annotations covering safety, the description adds some value 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the tool name and method, followed by a parameter list. It avoids unnecessary verbosity, but the parameter section is minimal and could be more informative. Overall, it's efficient but under-specified in content.

  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 mutation nature, 0% schema coverage, no output schema, and complex parameters (array of objects with specific fields), the description is incomplete. It doesn't explain the operation's impact, return values, or error conditions, making it inadequate for safe and effective use by an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameter names and types but doesn't explain their semantics—e.g., what 'serverId' refers to, what 'additionalPorts' array contains, or how targetPort and publishedPort relate. It fails to compensate for the schema's lack of documentation, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool updates Traefik ports, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'dokploy_settings_updateTraefikConfig' or 'dokploy_settings_getTraefikPorts', leaving ambiguity about when to use each. The purpose is clear but lacks sibling differentiation.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it's for adding ports to existing configurations or initial setup. This leaves the agent without clear usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_updateWebServerTraefikConfigC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), covering safety and idempotency. The description adds no behavioral context beyond the annotations, such as what 'update' entails (e.g., overwrites config, requires admin permissions) or side effects. It does not contradict annotations, but offers minimal additional value.

  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 and front-loaded, stating the tool's purpose in the first line. It wastes no words, though the parameter listing is redundant with the schema. The structure is efficient, but could be improved by integrating parameter details more meaningfully.

  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 updates a critical configuration (Traefik) with no output schema and 0% schema coverage, the description is incomplete. It lacks details on what the update does (e.g., reloads Traefik, affects web server behavior), error handling, or return values. Annotations help, but the description does not fill gaps for a mutation tool with significant impact.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only indicates 'traefikConfig' is a required string. The description lists the parameter but adds no meaning—no explanation of what the config should contain, format (e.g., YAML, JSON), or examples. With low coverage, the description fails to compensate, leaving the parameter poorly defined.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool updates the web server Traefik configuration, which is a specific verb (update) and resource (web server Traefik config). However, it does not differentiate from sibling tools like 'dokploy_settings_updateTraefikConfig' or 'dokploy_settings_updateMiddlewareTraefikConfig', leaving ambiguity about which Traefik config it targets. The purpose is clear but lacks sibling distinction.

  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 is provided on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., after reading configs), or exclusions. The description only lists parameters without usage instructions, leaving the agent to infer from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_writeTraefikEnvC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, implying a write action, which aligns with annotations. However, it lacks details on what 'env' contains, potential side effects, or error conditions, leaving behavioral gaps despite annotations.

  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 brief and front-loaded with the tool name and HTTP method, but includes a redundant header '[settings] settings.writeTraefikEnv (POST)' that adds little value. The parameter list is clear but could be more integrated into a cohesive sentence.

  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?

  For a write tool with 0% schema coverage, no output schema, and complex sibling tools, the description is inadequate. It fails to explain the purpose of 'env', when 'serverId' is needed, what the tool returns, or how it differs from similar tools, leaving significant gaps for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters 'env' and 'serverId' with types but provides no semantic meaning (e.g., what 'env' represents, format of 'serverId', default behavior if 'serverId' is omitted). This leaves parameters largely undocumented beyond basic schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool writes Traefik environment settings, which is a specific action ('writeTraefikEnv') on a resource ('settings'). However, it doesn't distinguish this from sibling tools like 'dokploy_settings_readTraefikEnv' or 'dokploy_settings_updateTraefikConfig', leaving the scope and differentiation unclear.

  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 guidance on when to use this tool versus alternatives. With many sibling tools related to Traefik settings (e.g., readTraefikEnv, updateTraefikConfig), there is no indication of prerequisites, context, or exclusions for this write operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sso_getTrustedOriginsC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive behavioral hints (read-only, non-destructive, idempotent, open-world), so the description's burden is lower. The description adds minimal value by specifying the HTTP method (GET), which aligns with read-only behavior. However, it doesn't provide any additional context about rate limits, authentication requirements, or what constitutes 'trusted origins' in this system.

  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 extremely concise (one bracketed phrase) but under-specified rather than efficiently informative. While it wastes no words, it fails to provide essential context that would help an agent understand the tool's purpose. The structure with brackets and parentheses is somewhat organized but doesn't compensate for the lack of meaningful content.

  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's simplicity (0 parameters, comprehensive annotations), the description is minimally adequate but leaves significant gaps. Without an output schema, the description should ideally indicate what kind of data is returned (list of origins, configuration objects, etc.). The annotations cover safety aspects, but the description doesn't help an agent understand what 'trusted origins' means in this SSO 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?

  With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters since none exist, and the empty input schema is self-explanatory. No additional parameter information is needed or provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[sso] sso.getTrustedOrigins (GET)' is a tautology that restates the tool name and adds minimal context (HTTP method). It doesn't specify what the tool actually does - whether it retrieves, lists, or fetches trusted origins. While 'GET' implies retrieval, the purpose remains vague compared to what a clear description would provide.

  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 is provided about when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for SSO configuration, or relationship to sibling SSO tools like dokploy_sso_addTrustedOrigin or dokploy_sso_removeTrustedOrigin. An agent would have to infer usage from the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_swarm_getNodeAppsC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, indicating a safe, non-destructive, repeatable operation with open-world semantics. The description adds minimal context with '(GET)' but doesn't disclose additional behavioral traits like rate limits, authentication needs, or what 'node apps' entail. With annotations covering core safety, a baseline 3 is appropriate as the description adds little beyond them.

  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 with two lines: a title-like statement and a parameter list. It's front-loaded with the core action, but the parameter section is minimal and could be more informative. There's no wasted text, making it efficient though under-specified.

  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 (swarm context, 1 parameter), lack of output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what 'node apps' are, the return format, or how the optional parameter affects results. Annotations help with safety, but overall context is insufficient for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only documents 'serverId' as an optional string without meaning. The description lists 'serverId (string, optional)' but adds no semantics—it doesn't explain what a serverId is, how to obtain it, or its impact on the operation. With low coverage, the description fails to compensate, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'swarm.getNodeApps (GET)' which indicates a GET operation for node apps in a swarm context, providing a basic verb+resource. However, it lacks specificity about what 'node apps' are (e.g., applications, services, containers) and doesn't differentiate from sibling tools like 'dokploy_swarm_getNodeInfo' or 'dokploy_swarm_getNodes', leaving the purpose somewhat vague.

  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 is provided on when to use this tool versus alternatives. The description mentions 'swarm' context but doesn't specify prerequisites, constraints, or when to choose this over similar tools like 'dokploy_swarm_getNodes' or 'dokploy_application_search', leaving the agent without usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_swarm_getNodesC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds minimal context by specifying it's a GET operation, but doesn't disclose behavioral traits like rate limits, authentication needs, or what data is returned. No contradiction with annotations exists.

  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 brief and front-loaded with the operation type, but includes redundant formatting like brackets and parentheses. It wastes space on a parameter list without elaboration, though it avoids unnecessary verbosity.

  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 (swarm node retrieval), lack of output schema, and low schema coverage, the description is incomplete. It doesn't explain return values, error conditions, or how it fits into the swarm context, leaving significant gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'serverId' as optional but doesn't explain its purpose (e.g., to filter nodes by server), format, or impact. With one parameter and no schema details, the description adds little meaning beyond the schema's structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states it's a GET operation for swarm nodes, which clarifies the verb and resource. However, it's vague about what 'getNodes' entails—whether it lists, retrieves details, or filters nodes—and doesn't differentiate from sibling tools like 'dokploy_cluster_getNodes' or 'dokploy_swarm_getNodeInfo', leaving ambiguity in purpose.

  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 is provided on when to use this tool versus alternatives. The description lacks context on prerequisites, such as needing swarm mode enabled, and doesn't mention sibling tools for comparison, leaving the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_volumeBackups_runManuallyC
  2.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds minimal behavioral context by specifying it's a POST request, implying a state-changing action, but doesn't elaborate on what 'runManually' does (e.g., triggers an immediate backup, may have side effects like resource usage, or requires specific permissions). With annotations covering basic traits, the description provides some value but lacks depth on execution behavior.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant information (repeating 'volumeBackups' and listing parameters without added value). It's structured as two lines, which is efficient, but the parameter listing is minimal and could be more informative without sacrificing conciseness.

  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 has no output schema, annotations provide basic hints, and schema coverage is 0%, the description is incomplete. It doesn't explain what happens when the tool is invoked (e.g., success/failure outcomes, return values like backup status), nor does it cover error conditions or dependencies. For a state-changing tool with one parameter, more context is needed to guide effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema only defines 'volumeBackupId' as a required string without descriptions. The description lists the parameter but adds no semantic meaning—it doesn't explain what a volumeBackupId is, where to find it, or its format (e.g., UUID, name). For a single parameter with no schema documentation, the description fails to compensate, leaving the parameter's purpose unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name 'volumeBackups.runManually (POST)' which implies it manually runs a volume backup, but it's vague about what 'runManually' entails compared to automated backups. It specifies the resource (volumeBackups) and verb (runManually), but doesn't clearly differentiate from sibling tools like 'dokploy_volumeBackups_create' or 'dokploy_backup_manualBackupCompose', leaving the exact purpose ambiguous.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing volume backup ID), exclusions, or compare it to other backup-related tools in the sibling list, such as 'dokploy_backup_manualBackupCompose' or 'dokploy_volumeBackups_create'. This lack of context makes it unclear when this specific manual run is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_killBuildC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true, idempotentHint=false, and openWorldHint=true, which the description doesn't contradict. The description adds minimal context by specifying the HTTP method (POST), but it doesn't elaborate on behavioral traits like what 'kill' entails (e.g., irreversible termination, effects on the application state, or error handling). However, with annotations covering key safety aspects, the description's addition is limited but not contradictory.

  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 brief but inefficiently structured—it repeats the tool name and includes a parameter list without adding value. It's front-loaded with redundant information, and the single sentence lacks clarity, making it somewhat concise but not well-organized for understanding.

  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 destructive nature (per annotations), one parameter with 0% schema coverage, no output schema, and complex sibling tools, the description is inadequate. It doesn't explain the outcome of killing a build, error conditions, or how it fits into the broader application lifecycle, leaving significant gaps for safe and correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'applicationId' as a required parameter but provides no semantic meaning beyond what the schema indicates (a string with minLength 1). With schema description coverage at 0%, the description fails to compensate by explaining what an applicationId is, where to find it, or format examples, leaving the parameter poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool name and HTTP method ('application.killBuild (POST)'), which implies it kills a build for an application, but it's vague about what 'killBuild' entails—whether it terminates an ongoing build process, cancels a queued build, or something else. It doesn't distinguish from siblings like 'dokploy_application_cancelDeployment' or 'dokploy_compose_killBuild', leaving the purpose unclear beyond the basic verb+resource.

  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 lists a parameter but provides no context on prerequisites, timing, or comparisons to sibling tools (e.g., 'dokploy_application_cancelDeployment' or 'dokploy_compose_killBuild'), leaving the agent without usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_certificates_removeC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a destructive, non-idempotent, open-world operation (destructiveHint: true, idempotentHint: false, openWorldHint: true). The description doesn't contradict these but adds minimal behavioral context beyond the name. It implies a POST request, which suggests mutation, aligning with annotations. However, it lacks details on side effects, permissions, or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) and a parameter list that doesn't add clarity. It's concise but could be more structured and informative without extra fluff.

  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 destructive nature (per annotations) and lack of output schema, the description is insufficient. It doesn't explain the outcome of removal, potential errors, or dependencies. For a critical operation like certificate deletion, more context is needed to ensure safe usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'certificateId' as a required string parameter but provides no semantic meaning, format, or examples. This adds little value beyond the schema, failing to clarify what a certificateId is or where to obtain it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a certificate ('certificates.remove'), which is a specific verb+resource. However, it doesn't distinguish this from sibling tools like 'dokploy_certificates_delete' (which doesn't exist in the list) or other removal tools in the system, leaving the scope ambiguous. It's clear but lacks sibling differentiation.

  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 guidance on when to use this tool versus alternatives. There are no explicit instructions on prerequisites, context, or exclusions. Sibling tools like 'dokploy_certificates_all' or 'dokploy_certificates_one' might be related, but no comparison is made.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_customRole_createC
  2.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a write operation (readOnlyHint=false) that's non-destructive and non-idempotent, with open-world semantics. The description adds minimal behavioral context beyond annotations—it confirms creation but doesn't specify what happens on duplicate role names, permission validation, or response format. No contradiction with annotations exists.

  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 brief but includes redundant formatting (brackets, HTTP method) and lacks front-loaded clarity. It wastes space on obvious structure instead of focusing on essential usage information, though it's 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?

  For a creation tool with 2 parameters, 0% schema coverage, no output schema, and nested objects (permissions), the description is inadequate. It fails to explain the permission object structure, success/failure responses, or any system-specific constraints, leaving the agent poorly equipped to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters (roleName and permissions) but provides no semantic details—no explanation of permission structure, valid values, constraints (e.g., roleName length 1-50), or examples. This leaves significant gaps in understanding parameter usage.

  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 creates a custom role with specific parameters (roleName and permissions). It uses a specific verb ('create') and resource ('customRole'), but doesn't distinguish it from sibling tools like dokploy_customRole_update or dokploy_customRole_remove, which would require explicit differentiation.

  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 is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., admin permissions), when not to use it, or how it relates to sibling tools like dokploy_customRole_update or dokploy_customRole_all.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_customRole_removeC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a deletion action ('remove'). The description adds value by specifying the HTTP method (POST), which isn't covered by annotations, but it lacks details on side effects (e.g., impact on users with this role) or error conditions. No contradiction with annotations exists.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets and parentheses) that doesn't add clarity. It could be more streamlined by integrating the parameter list more naturally, though it avoids unnecessary verbosity.

  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 destructive nature (destructiveHint=true), no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the outcome of removal, potential errors, or system impacts, leaving gaps for a mutation tool with significant behavioral implications.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists 'roleName' as a required string parameter without explaining its format, constraints, or examples. This adds minimal meaning beyond the schema, failing to address the coverage gap effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a custom role, which is a specific verb ('remove') and resource ('customRole'), but it's vague about what 'customRole' refers to in the context of the Dokploy system. It doesn't distinguish this from sibling tools like 'dokploy_customRole_create' or 'dokploy_customRole_update', leaving ambiguity about the exact scope of the operation.

  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 guidance on when to use this tool versus alternatives, such as 'dokploy_customRole_update' for modifying roles or 'dokploy_customRole_all' for listing them. There are no prerequisites, exclusions, or context provided, making it unclear when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_deployment_allByComposeC
  2.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover key behavioral traits (read-only, non-destructive, idempotent, open-world), so the description's burden is lower. It adds minimal context by specifying the HTTP method (GET) and parameter, but doesn't disclose additional details like response format, pagination, or error handling. No contradiction with annotations exists.

  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 front-loaded with the tool name and method, followed by a clear parameter list. It's efficient with no wasted sentences, though the formatting with brackets and parentheses is slightly cluttered.

  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 (filtered list operation), lack of output schema, and low schema coverage, the description is insufficient. It doesn't explain the return type (e.g., list of deployments), structure, or any behavioral nuances, leaving the agent under-informed for proper use.

  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 0%, but the description explicitly lists 'composeId' as a required string parameter, adding meaning beyond the bare schema. However, it doesn't explain what a composeId is, its format, or where to obtain it, leaving significant gaps in parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves deployments by compose ID ('deployment.allByCompose (GET)'), which is a specific verb+resource combination. However, it doesn't distinguish itself from sibling deployment tools like 'dokploy_deployment_all' or 'dokploy_deployment_allByServer', leaving the purpose somewhat vague in context.

  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 explicit guidance is provided on when to use this tool versus alternatives. The description only lists the parameter without explaining the context or prerequisites for filtering deployments by compose ID, offering no help in tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_deployment_killProcessC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide clear hints (destructiveHint: true, readOnlyHint: false, etc.), but the description adds no behavioral context beyond what's inferred from 'killProcess'. It doesn't explain what 'kill' entails (e.g., forceful termination, side effects, or permissions required), though annotations cover the safety profile adequately, so the bar is lower.

  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 brief but not front-loaded with key information; it starts with a redundant label '[deployment] deployment.killProcess (POST)' before listing parameters. It avoids fluff but could be more structured to highlight the tool's action and context first.

  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 destructive nature (per annotations), no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on what 'killProcess' does operationally, potential outcomes, or error conditions, making it inadequate for safe and effective use by an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'deploymentId' as a required parameter without adding any meaning, format, or examples. It fails to compensate for the lack of schema descriptions, leaving the parameter's purpose and constraints unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool kills a process for a deployment, which is a specific action ('killProcess') on a resource ('deployment'), but it doesn't distinguish it from sibling tools like 'dokploy_application_killBuild' or 'dokploy_compose_killBuild', leaving ambiguity about when to use this specific deployment kill tool versus others.

  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 is provided on when to use this tool versus alternatives. The description only lists parameters without context, prerequisites, or comparisons to sibling tools like 'stop' or 'cancelDeployment' operations, leaving the agent to guess based on the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_docker_getContainersByAppLabelC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a read-only, non-destructive, idempotent, and open-world operation, which the description doesn't contradict. The description adds value by specifying it's a GET operation and implying it returns containers filtered by app label, providing useful context beyond the annotations.

  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 brief but front-loaded with the tool name and method. However, it includes redundant information like '[docker] docker.getContainersByAppLabel' and formats parameters in a list that doesn't add semantic value, making it somewhat inefficient.

  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 Docker container retrieval, 0% schema description coverage, no output schema, and rich annotations, the description is incomplete. It lacks details on what the tool returns (e.g., container list format), error conditions, or how the app label filtering works, leaving significant gaps for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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, but it only lists parameter names and types without explaining their meaning. For example, it doesn't clarify what 'appName' represents (e.g., label key/value), what 'serverId' refers to, or the implications of the 'type' enum choices (standalone vs. swarm).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves Docker containers by app label, which is a clear purpose. However, it doesn't specify what 'app label' means in this context or how it differs from similar tools like 'dokploy_docker_getContainersByAppNameMatch' or 'dokploy_docker_getContainers', leaving sibling differentiation vague.

  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 is provided on when to use this tool versus alternatives. The description lists parameters but doesn't explain the context for choosing this specific container lookup method over other Docker container retrieval tools in the sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_domain_deleteC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a deletion action. The description adds value by specifying the HTTP method (POST), which isn't covered by annotations, but it doesn't detail consequences (e.g., irreversible deletion, impact on linked resources) or error conditions beyond what annotations provide.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets around '[domain]') and a parameter list that repeats schema info without adding value. It could be more streamlined by focusing on unique insights.

  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 destructive nature (destructiveHint=true), no output schema, and low parameter coverage, the description is inadequate. It fails to explain the deletion's effects, return values, or error handling, leaving gaps in understanding for safe and correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'domainId' as a required string parameter, which matches the schema, but adds no semantic context (e.g., what a domainId is, format examples, or where to find it). This leaves the parameter meaning unclear beyond basic type information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool deletes a domain ('domain.delete') and mentions the required parameter 'domainId', which clarifies the verb and resource. However, it doesn't distinguish this from sibling tools like 'dokploy_domain_create' or 'dokploy_domain_update', leaving the purpose somewhat vague in context.

  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 is provided on when to use this tool versus alternatives (e.g., 'dokploy_domain_update' for modifications or 'dokploy_domain_one' for viewing). The description lacks context about prerequisites, such as needing an existing domain, or exclusions, like not being usable for non-domain resources.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mysql_stopC
  2.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is not read-only, not destructive, not idempotent, and open-world. The description adds minimal behavioral context beyond annotations—it implies a state change (stopping) but doesn't detail effects like service interruption, reversibility, or permissions required. No contradiction with annotations exists.

  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 brief but includes redundant formatting (brackets, HTTP method) and a parameter list that adds little value. It is front-loaded with the core action but could be more streamlined by omitting the parameter enumeration.

  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 (state-changing operation), lack of output schema, and minimal annotations, the description is insufficient. It doesn't cover expected outcomes, error conditions, or side effects, leaving significant gaps for an agent to understand the tool fully.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists the parameter 'mysqlId' without explaining its meaning, format, or where to obtain it. This fails to compensate for the lack of schema documentation, leaving the parameter's semantics unclear.

  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 verb ('stop') and resource ('mysql'), making the purpose evident. It distinguishes from siblings like 'dokploy_mysql_start' by specifying the opposite action, though it doesn't explicitly contrast with other mysql tools like 'dokploy_mysql_remove' or 'dokploy_mysql_reload'.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., the MySQL instance must be running), exclusions, or comparisons to similar tools like 'dokploy_mysql_changeStatus' or 'dokploy_application_stop'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_notification_removeC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying removal. The description adds value by specifying the HTTP method (POST) and parameter requirement, though it doesn't detail side effects like whether removal is permanent or if there are confirmation steps. No contradiction with annotations exists.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets and parentheses) and lacks efficient structuring. While not verbose, it could be more polished and informative without adding unnecessary length.

  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 destructive nature (annotations show destructiveHint=true), no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the outcome (e.g., success response, error handling) or behavioral nuances, making it inadequate for a tool that performs a removal operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 mentions notificationId as a required string but provides no semantic context (e.g., format, source, or examples). This leaves the parameter meaning unclear beyond its basic type, failing to add sufficient value over the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a notification with a required notificationId parameter, which clarifies the basic action. However, it doesn't specify what type of notification (e.g., system alert, user message) or distinguish it from sibling notification tools like dokploy_notification_all or dokploy_notification_one, making it somewhat vague.

  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 guidance on when to use this tool versus alternatives, such as when to remove versus update or create notifications. It lacks context on prerequisites (e.g., needing an existing notification ID) or exclusions, leaving the agent with minimal usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_inviteMemberC
  2.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds minimal context by specifying it's a POST request, implying mutation, but doesn't elaborate on behavioral aspects like whether it sends an email invitation, requires specific permissions, or has rate limits. It doesn't contradict annotations, but adds little beyond them.

  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 brief and front-loaded with the tool name and HTTP method, but includes redundant formatting (brackets, parentheses) and a parameter list that merely repeats schema info without added value. It could be more streamlined by integrating parameter details meaningfully or omitting the list if not explanatory.

  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 mutation nature (non-read-only), lack of output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what happens upon invocation (e.g., invitation sent, pending status), error conditions, or return values, leaving the agent with incomplete context for safe and effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters 'email' and 'role' as required but provides no semantic details (e.g., valid email formats, role options like 'admin' or 'member', or constraints). This leaves critical usage information undocumented, failing to adequately supplement the bare 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 clearly states the action ('inviteMember') and resource ('organization'), specifying it's a POST operation. It distinguishes itself from sibling tools like 'dokploy_organization_updateMemberRole' by focusing on invitation rather than role modification, though it doesn't explicitly contrast with other organization tools like 'dokploy_organization_allInvitations'.

  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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin permissions), exclusions (e.g., not for existing members), or related tools like 'dokploy_organization_allInvitations' for viewing invitations or 'dokploy_organization_removeInvitation' for revocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_updateMemberRoleC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide good behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), but the description adds no additional context. It doesn't mention authentication requirements, rate limits, or what happens on success/failure. Since annotations cover the core safety profile, the description gets a baseline score but misses opportunities to add value beyond structured data.

  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 brief but inefficiently structured. It repeats the tool name in brackets and includes a POST method note that adds little value. The parameter list is minimal but doesn't front-load critical information. While not verbose, it wastes space on redundant elements instead of focusing on helpful content.

  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?

  For a mutation tool with 2 parameters, 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or side effects. Annotations help with safety, but the description fails to provide necessary context for effective use, especially given the lack of parameter documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description lists parameter names but adds no semantic meaning—it doesn't explain what 'memberId' refers to, what valid 'role' values are, or format requirements. This fails to compensate for the schema's lack of descriptions, leaving parameters poorly understood.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool updates a member's role in an organization, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'dokploy_organization_inviteMember' or 'dokploy_organization_removeInvitation' that also manage organization members. The purpose is understandable but lacks sibling distinction.

  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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing admin permissions), when this operation is appropriate, or what other tools might be related (like viewing members first). Usage context is entirely absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_postgres_createC
  2.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation with open-world semantics. The description adds that it's a POST request (implying creation) and lists parameters, but doesn't provide additional behavioral context like what happens on duplicate names, whether it deploys immediately, or any rate limits. Since annotations cover basic safety, the description adds minimal value beyond them.

  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 structured with a clear header and parameter list, but includes redundant information (e.g., repeating 'postgres' and listing all parameters verbatim without explanation). It could be more concise by focusing on high-level purpose and key parameters rather than enumerating every field. The structure is functional but not optimally efficient.

  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 (9 parameters, 5 required), lack of output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool returns, error conditions, or dependencies. For a creation tool with many parameters and no structured documentation, more contextual information is needed to guide proper usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description must compensate by explaining parameter meanings. It only lists parameter names and types without any semantic context (e.g., what 'environmentId' refers to, format constraints for 'databaseName', or what 'dockerImage' defaults to). This leaves critical gaps in understanding how to use the 9 parameters effectively.

  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 creates a PostgreSQL database with specific required parameters (name, databaseName, databaseUser, databasePassword, environmentId). It uses the verb 'create' and specifies the resource 'postgres', making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like dokploy_postgres_update or dokploy_postgres_deploy, which prevents a perfect score.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing environment or server), when not to use it, or refer to sibling tools like dokploy_postgres_update for modifications. This leaves the agent with insufficient context for proper tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_redis_removeC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide critical behavioral hints (destructiveHint=true, readOnlyHint=false, idempotentHint=false, openWorldHint=true), but the description adds minimal context by specifying it's a POST operation. It doesn't elaborate on what 'remove' entails (e.g., data deletion, resource cleanup) or potential side effects beyond annotations. No contradiction with annotations exists, and the description adds some operational detail.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, parentheses) and a parameter list that doesn't add semantic clarity. It avoids verbosity but could be more structured (e.g., separating purpose from parameters). Some waste exists in the presentation.

  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 destructive nature (per annotations), no output schema, and low parameter coverage, the description is insufficient. It lacks details on what happens post-removal (e.g., confirmation, error handling), dependencies, or impact on related resources. For a destructive operation with one parameter, more context is needed to ensure safe usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It lists 'redisId' as a required string but provides no semantic meaning (e.g., what constitutes a valid Redis ID, format examples, or where to find it). This adds minimal value beyond the schema's structural definition, failing to address the coverage gap adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a Redis resource, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'dokploy_redis_delete' (which doesn't exist in the list) or other removal tools in the system. The purpose is clear but lacks sibling differentiation.

  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 guidance on when to use this tool versus alternatives. There are no explicit when/when-not instructions, no mention of prerequisites (e.g., Redis must be stopped first), and no reference to sibling tools like 'dokploy_redis_changeStatus' or 'dokploy_redis_stop' that might be related. Usage is implied but not articulated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_removeC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a destructive, non-idempotent, open-world operation (destructiveHint: true, idempotentHint: false, openWorldHint: true), which the description doesn't explicitly state. However, the description doesn't contradict these annotations—'remove' aligns with destructive behavior. It adds minimal context beyond annotations, such as the HTTP method (POST), but lacks details on permissions, side effects, or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the tool signature ('[server] server.remove (POST)'), but it includes redundant parameter listing that adds little value. It could be more structured by integrating parameter details into a cohesive sentence, though it avoids unnecessary verbosity.

  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?

  For a destructive tool with no output schema and minimal annotations, the description is incomplete. It doesn't cover critical aspects like what 'remove' entails (e.g., deletion, deprovisioning), potential impacts, success/error responses, or dependencies. Given the complexity implied by the sibling tools, more context is needed for safe and effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only lists 'serverId' as a required string parameter without explaining what it represents (e.g., a server identifier, format, or where to find it). Given the low coverage, the description fails to compensate by adding meaningful semantic context beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a server ('server.remove'), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'dokploy_server_delete' (which doesn't exist in the list) or other removal tools in the system, making it somewhat vague about its specific scope within the server management context.

  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 is provided on when to use this tool versus alternatives. The sibling list includes many server-related tools (e.g., 'dokploy_server_create', 'dokploy_server_update'), but the description doesn't mention prerequisites, when removal is appropriate, or what happens to associated resources, leaving usage unclear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_readTraefikEnvC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying 'GET', which aligns with read-only behavior. However, it does not disclose additional traits like rate limits, authentication needs, or what 'TraefikEnv' contains. With annotations providing strong coverage, the description adds some value but not rich behavioral details.

  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 brief and front-loaded with the tool name and 'GET', but includes redundant formatting like brackets and a label that could be omitted. The parameter listing is clear but not integrated into a cohesive sentence. It avoids fluff but could be more structured for better 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's low complexity (1 optional parameter) and rich annotations, the description is minimally adequate. However, without an output schema, it fails to explain what 'TraefikEnv' returns or its format. For a read operation, this gap reduces completeness, though annotations help cover safety aspects.

  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 0%, so the description must compensate. It lists the parameter 'serverId (string, optional)', which matches the schema, but does not explain what 'serverId' is, its format, or when it should be provided. This adds basic parameter awareness but lacks meaningful semantics beyond what the schema already indicates through its type and optionality.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description restates the tool name and title ('settings.readTraefikEnv') without clarifying what 'TraefikEnv' refers to or what reading it entails. It includes 'GET' which hints at retrieval, but lacks a specific verb-resource combination that distinguishes it from sibling tools like 'dokploy_settings_readTraefikConfig' or 'dokploy_settings_readTraefikFile'. This is closer to tautology than clear purpose.

  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 is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions. Given the many sibling tools with similar names (e.g., readTraefikConfig, readTraefikFile), the absence of differentiation leaves the agent without clear usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_settings_readTraefikFileC
  2.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide comprehensive behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true). The description adds minimal value by specifying this is a GET operation, which aligns with the read-only nature indicated by annotations. However, it doesn't disclose additional behavioral traits like what happens if the file doesn't exist, authentication requirements, or rate limits.

  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 appropriately concise with just two lines: one stating the operation and HTTP method, and another listing parameters. There's no wasted space or redundant information. However, the structure could be improved by front-loading the purpose more clearly rather than starting with '[settings] settings.readTraefikFile'.

  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 that annotations provide good behavioral coverage and there are only 2 parameters, the description is minimally adequate. However, with 0% schema description coverage and no output schema, the description should do more to explain parameter semantics and expected return values. For a file reading operation, additional context about file format, encoding, or error conditions would be helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description lists parameter names and types but adds no semantic meaning beyond what's already in the schema. It doesn't explain what 'path' represents (e.g., file path relative to what?), what 'serverId' is for, or provide any examples or constraints beyond the minimal schema requirements.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool reads a Traefik file, which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like dokploy_settings_readTraefikConfig or dokploy_settings_readTraefikEnv, which appear to perform similar read operations on Traefik-related data. The purpose is clear but lacks sibling distinction.

  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 guidance on when to use this tool versus alternatives. There are multiple sibling tools with 'readTraefik' in their names, but the description doesn't explain what makes this tool different or when it should be preferred over those other options. No usage 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_settings_toggleRequestsC
  2.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, implying it changes server state, which aligns with annotations. However, it doesn't provide additional behavioral context like what 'toggleRequests' affects, side effects, or error conditions. No contradiction with annotations exists.

  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 brief and front-loaded with the tool's action. It wastes no words but could be more structured (e.g., separating the POST method note). The parameter listing is minimal yet clear. Overall, it's efficient but lacks polish.

  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 mutation nature (POST), lack of output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the outcome of toggling, potential side effects, or error handling. For a settings modification tool, this leaves significant gaps for an agent to operate safely.

  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 0%, with one required boolean parameter 'enable'. The description lists the parameter but adds no semantic meaning beyond what the schema provides (e.g., what enabling/disabling does, default state). With 0% coverage, the description partially compensates by naming the parameter but fails to explain its purpose.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool toggles requests in settings, which is a clear verb+resource combination. However, it doesn't specify what 'requests' refers to (e.g., API requests, monitoring requests) or how this differs from other settings toggle tools like 'dokploy_settings_toggleDashboard'. The purpose is understandable but lacks specificity and sibling differentiation.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or when-not-to-use scenarios. Given the many sibling tools, this absence leaves the agent without context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sso_deleteProviderC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a destructive, non-idempotent, non-read-only operation with open-world semantics. The description doesn't contradict these annotations, and it adds value by specifying the HTTP method (POST), which isn't covered by annotations. However, it doesn't provide additional context like authentication requirements, error conditions, or what happens to associated data, leaving some behavioral aspects unclear.

  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 brief but not optimally structured. It front-loads the action ('sso.deleteProvider') and includes the HTTP method, which is useful. However, the parameter listing is redundant with the schema and adds no value. The description could be more concise by omitting the parameter line or integrating it meaningfully.

  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 destructive nature (per annotations), single parameter with 0% schema coverage, and lack of output schema, the description is inadequate. It doesn't explain the parameter's purpose, potential side effects, or what to expect upon success/failure. For a deletion tool with high stakes, more context is needed to ensure safe and correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 0%, meaning the parameter 'providerId' has no documentation in the schema. The description only repeats the parameter name without adding any semantic meaning (e.g., what a providerId is, format examples, or where to find it). For a single required parameter with zero schema coverage, this is a significant gap that leaves the agent guessing.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool deletes an SSO provider ('sso.deleteProvider'), which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'dokploy_sso_removeTrustedOrigin' or 'dokploy_sso_update', leaving the scope somewhat vague. The description is functional but lacks differentiation from related SSO operations.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing provider), exclusions, or related tools like 'dokploy_sso_listProviders' or 'dokploy_sso_update'. The agent must infer usage from the name alone, which is insufficient for a destructive operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_user_deleteApiKeyC
  2.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide critical hints: destructiveHint=true indicates permanent deletion, and readOnlyHint=false confirms it's a mutation. The description adds the HTTP method (POST), which is useful context not in annotations. However, it doesn't disclose behavioral details like authentication requirements, error conditions, or idempotency implications (idempotentHint=false), leaving gaps in understanding.

  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 brief and front-loaded with the tool name and method, but it wastes space by repeating the name in brackets and includes a redundant 'Parameters:' section that adds little value. It could be more efficiently structured without sacrificing clarity.

  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 destructive nature (destructiveHint=true), no output schema, and low schema coverage, the description is inadequate. It doesn't explain the outcome of deletion (e.g., success response, error handling), security implications, or dependencies, leaving the agent with incomplete context for safe invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no param documentation. The description lists 'apiKeyId' as a required string but adds no semantic meaning—it doesn't explain what an API key ID is, where to find it, or format expectations. This minimal info fails to compensate for the lack of schema descriptions.

  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 verb ('delete') and resource ('ApiKey'), making the purpose understandable. It distinguishes from sibling tools like 'dokploy_user_createApiKey' by specifying deletion. However, it doesn't explicitly mention the user context beyond the tool name prefix, leaving some 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 Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing an existing API key), exclusions, or comparisons to other user management tools in the sibling list. This leaves the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_volumeBackups_deleteC
  2.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true (irreversible deletion) and readOnlyHint=false (mutation), which the description aligns with by implying deletion. The description adds value by specifying the HTTP method (POST), which isn't covered by annotations, providing useful context for invocation. No contradiction with annotations exists.

  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 brief but includes redundant information (repeating 'volumeBackups' and the tool name) and lacks a clear, front-loaded purpose statement. It could be more structured, such as starting with a direct action description, but it avoids unnecessary verbosity.

  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 destructive nature (annotations show destructiveHint=true), no output schema, and low parameter coverage, the description is inadequate. It doesn't address critical aspects like what happens post-deletion (e.g., confirmation, error handling), permissions required, or how to verify the backup exists before deletion, leaving gaps for safe tool use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'volumeBackupId' as a required string parameter but doesn't explain what this ID is, how to obtain it, or its format (e.g., from 'dokploy_volumeBackups_list' or 'dokploy_volumeBackups_one'). This leaves the parameter meaning unclear beyond the schema's basic type constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool deletes volume backups ('volumeBackups.delete'), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'dokploy_backup_remove' or 'dokploy_volumeBackups_remove' (if they exist in the list, though not explicitly shown), making it somewhat vague about its specific scope within the backup system.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing a valid volumeBackupId), exclusions, or comparisons to other deletion tools in the sibling list, such as 'dokploy_backup_remove' for general backups.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_domain_byApplicationIdC
  2.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover key behavioral traits (read-only, non-destructive, idempotent, open-world), so the description's burden is lower. It adds minimal context by specifying the HTTP method (GET), but doesn't disclose additional details like rate limits, authentication needs, or what happens if the applicationId is invalid. No contradiction with annotations exists.

  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 brief and front-loaded with the tool name and method, followed by parameter details. It avoids unnecessary fluff, but the formatting with brackets and lack of complete sentences slightly reduces readability. Overall, it's efficient but could be more polished.

  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's simplicity (1 parameter, no output schema) and rich annotations, the description is minimally adequate. However, it lacks details on return values (e.g., what domain data is fetched), error conditions, or examples, leaving gaps for an agent to fully understand the tool's behavior in context.

  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 0%, so the description must compensate. It lists the parameter (applicationId) and its type/requirement, but doesn't explain its meaning (e.g., what constitutes a valid ID, where to find it, or format examples). This adds basic semantics but falls short of fully clarifying usage, resulting in a baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves domain information by application ID ('domain.byApplicationId (GET)'), which clarifies the verb (GET) and resource (domain). However, it doesn't differentiate from sibling tools like 'dokploy_domain_byComposeId' or 'dokploy_domain_one', leaving ambiguity about when to use this specific tool versus others for domain-related queries.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether the application must exist or be deployed, and doesn't mention sibling tools like 'dokploy_domain_byComposeId' for similar queries. This leaves the agent without clear usage instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mariadb_startC
  2.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive (destructiveHint=false), non-idempotent (idempotentHint=false) operation with open-world semantics (openWorldHint=true). The description adds that it's a POST request, implying it's an action that changes state, which aligns with annotations. However, it doesn't provide additional behavioral details like side effects (e.g., service availability), error conditions, or performance implications.

  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 brief and front-loaded with the tool name and HTTP method, but it's inefficiently structured as a code-like snippet rather than natural language. The parameter listing is redundant with the schema. It could be more concise by omitting the parameter details and focusing on purpose.

  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 performs a state-changing operation (starting a database) with no output schema, the description is incomplete. It doesn't explain what happens on success (e.g., the MariaDB service becomes active) or failure, nor does it cover authentication needs, rate limits, or dependencies. Annotations provide some safety context, but more operational details are needed for effective use.

  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 description lists the parameter 'mariadbId' as required, but the schema already defines it as a required string with minLength=1. With 0% schema description coverage, the description adds no extra semantic meaning (e.g., what a mariadbId is, format examples, or where to find it). The baseline is 3 since the schema fully defines the parameter, but the description doesn't compensate for the lack of schema descriptions.

  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 action ('start') and resource ('mariadb'), making the purpose understandable. It distinguishes from sibling tools like 'dokploy_mariadb_stop' by specifying the opposite action. However, it doesn't explicitly mention what 'starting' entails operationally (e.g., initiating a database service).

  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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the MariaDB instance must exist and be stopped), nor does it reference related tools like 'dokploy_mariadb_stop' or 'dokploy_mariadb_changeStatus' for context. The description lacks any usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mounts_allNamedByApplicationIdC
  2.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal context by specifying it's a GET operation, but doesn't disclose behavioral traits like pagination, error conditions, or rate limits. No contradiction with annotations.

  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 brief and front-loaded with the tool name and HTTP method, but includes redundant formatting (brackets, parentheses) and could be more polished. It efficiently states the parameter without unnecessary details, though it lacks a clear introductory sentence.

  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 has one parameter, rich annotations, but no output schema, the description is moderately complete. It covers the basic operation and parameter but lacks details on return values, error handling, or how it fits into the broader context of mount management. Adequate for a simple read tool but with gaps.

  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 0%, but the description lists 'applicationId' as a required string parameter, matching the schema. It doesn't add meaning beyond the schema (e.g., format examples, valid IDs, or relationship to other tools). With one parameter and no schema descriptions, baseline 3 is appropriate as it minimally compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves mounts for an application ID, but it's vague about what 'mounts' are (e.g., storage volumes, configurations) and doesn't specify the return format. It distinguishes from some siblings like 'dokploy_mounts_listByServiceId' by using 'applicationId', but doesn't explain how it differs from other mount-related tools like 'dokploy_mounts_one' or 'dokploy_mounts_create'.

  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 explicit guidance on when to use this tool versus alternatives. The description mentions 'applicationId' but doesn't specify prerequisites (e.g., the application must exist) or compare it to siblings like 'dokploy_mounts_listByServiceId' for service-level mounts. Usage is implied by the parameter name only.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_mounts_listByServiceIdC
  2.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide comprehensive hints (read-only, non-destructive, idempotent, open-world), so the description's burden is lower. It adds minimal behavioral context by specifying the HTTP method (GET) and listing parameters, but doesn't describe output format, pagination, or error handling. No contradiction with annotations exists.

  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 front-loaded with the tool name and HTTP method, followed by a clear parameter list. It's efficient with no wasted sentences, though the formatting as a code block might reduce readability. Every element serves a purpose.

  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's simplicity (2 parameters, read-only operation with good annotations), the description is adequate but incomplete. It lacks output details (no schema provided), doesn't explain the relationship to other mount tools, and omits error cases. For a list operation, more context on result structure would be helpful.

  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 0%, but the description lists both parameters with types and requirements, adding meaningful semantics beyond the bare schema. However, it doesn't explain what 'serviceId' or 'serviceType' represent in context, or how they affect the results. With two parameters and no schema descriptions, this provides basic compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool lists mounts by service ID, which is a clear verb+resource combination. However, it doesn't differentiate from sibling mount tools like 'dokploy_mounts_allNamedByApplicationId' or 'dokploy_mounts_one', leaving the scope and relationship ambiguous. The description is functional but lacks sibling distinction.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, nor does it reference sibling tools for comparison. Usage is implied through parameter requirements but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_organization_createC
  2.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds that it's a POST request, implying a write operation, which aligns with annotations. However, it doesn't provide additional behavioral context like authentication requirements, rate limits, or what happens on duplicate 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 brief and structured with a clear header and parameter list, making it easy to scan. However, the formatting with brackets and parentheses could be slightly cleaner, and it lacks a complete sentence explaining the tool's purpose upfront.

  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 no output schema and 0% schema description coverage, the description is incomplete. It doesn't explain what the tool returns (e.g., organization ID, success status) or error conditions, which is critical for a creation tool with write operations indicated by annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists parameters 'name' and 'logo' with types and optionality, but doesn't explain what these parameters represent (e.g., organization name format, logo URL or base64 string), leaving semantics unclear beyond basic schema information.

  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 creates an organization with required name and optional logo parameters, specifying the action and resource. However, it doesn't differentiate from sibling organization tools like 'dokploy_organization_update' or 'dokploy_organization_delete', which would require explicit comparison.

  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 versus alternatives is provided. The description lists parameters but doesn't mention prerequisites, when this should be used instead of other organization tools, or any contextual constraints for creating an organization.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_schedule_oneC
  2.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal value by specifying it's a GET operation, which aligns with annotations but doesn't provide additional context like rate limits, authentication needs, or what data is returned. No contradiction with annotations exists.

  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 brief and front-loaded with the operation type (GET), but it includes redundant formatting (brackets and parentheses) and could be more polished. It efficiently states the core action and parameter in two lines, with no unnecessary sentences, though the structure is slightly informal.

  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 has one parameter, no output schema, and rich annotations, the description is minimally adequate. It covers the basic operation but lacks details on return values, error handling, or how it fits with siblings. For a simple read tool, it meets the minimum but doesn't provide full context for effective use.

  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 0%, so the schema only documents the parameter type and requirement without descriptions. The description lists 'scheduleId' as a required string but adds no meaning beyond what's in the schema (e.g., format, source, or examples). With one parameter and high schema coverage for structure, the baseline is 3, as the description doesn't compensate for the lack of semantic details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool is a GET operation on a 'schedule' resource, which provides a basic purpose. However, it doesn't specify what 'schedule.one' means (likely retrieving a single schedule) or how it differs from sibling tools like 'dokploy_schedule_list' or 'dokploy_schedule_create'. The description is vague about the exact action and resource scope.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools (e.g., 'dokploy_schedule_list' for listing multiple schedules or 'dokploy_schedule_create' for creating one), nor does it specify prerequisites like needing a valid scheduleId. Usage is implied only by the parameter requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_server_allC
  2.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already provide comprehensive behavioral information (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), which tells the agent this is a safe, repeatable read operation. The description adds minimal value beyond this, but doesn't contradict the annotations. Since annotations cover the key behavioral traits, the bar is lower, and the description doesn't need to repeat what's already declared.

  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 extremely concise ('[server] server.all (GET)'), which could be seen as efficient, but it's under-specified rather than appropriately concise. It lacks essential context about what the tool actually does. While it's front-loaded (the entire description is one short phrase), it fails to provide meaningful information, making this more of a deficiency than true conciseness.

  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's zero parameters and comprehensive annotations, the description is minimally adequate but incomplete. The annotations cover safety and behavioral aspects, but the description doesn't explain what 'server.all' retrieves or returns. Without an output schema, the agent has no information about the response format or structure. For a read operation, knowing what data is returned is crucial, making this description incomplete despite the good annotation coverage.

  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 schema description coverage is 100% (though there are no parameters to describe). With no parameters, the description doesn't need to add parameter semantics. The baseline for zero parameters is 4, as there's nothing to compensate for and the schema adequately documents the empty input structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description '[server] server.all (GET)' is a tautology that essentially restates the tool name and title with minimal added meaning. It indicates this is a GET operation on a server resource, but doesn't specify what 'all' refers to (e.g., all servers, all server data, all server configurations). Compared to sibling tools like dokploy_server_one or dokploy_server_create, the distinction is implied but not clearly articulated.

  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 is provided about when to use this tool versus alternatives. The description doesn't mention any prerequisites, appropriate contexts, or when not to use it. With numerous sibling tools available (like dokploy_server_one for single server retrieval or dokploy_server_count for counting), the agent receives no help in selecting between them.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_sshKey_oneC
  2.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide strong behavioral hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), indicating a safe, non-destructive, repeatable read operation. The description adds minimal value by specifying it's a GET request, but doesn't disclose additional context like authentication needs, rate limits, or error conditions. No contradiction with annotations exists.

  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 brief but not well-structured. It includes the tool name in brackets and 'GET', but the parameter listing is minimal and lacks explanatory context. While concise, it could be more informative without adding unnecessary length.

  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 simple input schema (one required parameter) and rich annotations, the description is somewhat complete for a basic read operation. However, with no output schema and 0% parameter coverage, it should explain the return value (e.g., SSH key details) and parameter semantics more clearly to be fully helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description only lists 'sshKeyId (string, required)' without explaining what an SSH key ID is, its format, or where to obtain it. This fails to compensate for the lack of schema documentation, leaving the parameter's meaning unclear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'sshKey.one (GET)' which indicates a GET operation on an SSH key resource, but it's vague about what 'one' means (likely retrieving a single SSH key). It doesn't clearly distinguish this from sibling tools like 'dokploy_sshKey_all' (list all) or 'dokploy_sshKey_get' (if existed), though the name suggests it retrieves a specific SSH key by ID.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'dokploy_sshKey_all' for listing all SSH keys or 'dokploy_sshKey_create' for creating new ones, leaving the agent to infer usage from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_stripe_createCheckoutSessionC
  2.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation with open-world hints. The description doesn't contradict these but adds minimal behavioral context—it only lists parameters without explaining what the tool actually does (e.g., initiates a payment flow, returns a session URL). For a mutation tool with annotations, this is basic but not misleading.

  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 front-loaded with the tool name and method, followed by a structured parameter list. It's efficient with no wasted sentences, though the parameter formatting is slightly verbose. Every part serves a purpose.

  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?

  For a mutation tool with no output schema and 4 required parameters, the description is incomplete. It lacks explanation of what the tool returns (e.g., a session ID, URL), error conditions, or side effects. Given the complexity of payment processing, more context is needed for effective use.

  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 compensates by listing all four parameters with their types and constraints (e.g., tier enum values, serverQuantity minimum implied). This adds meaningful semantics beyond the bare schema, though it doesn't explain what each parameter means in context (e.g., what 'tier' represents).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool creates a Stripe checkout session, which is a specific verb+resource. However, it doesn't distinguish this from sibling tools like 'dokploy_stripe_createCustomerPortalSession' or 'dokploy_stripe_upgradeSubscription', nor does it explain what a checkout session is in the Dokploy context.

  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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a Stripe account setup), typical use cases, or when to choose this over other payment-related tools in the sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_customRole_updateB
  3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a mutable (readOnlyHint=false), non-destructive (destructiveHint=false), idempotent (idempotentHint=true), and open-world (openWorldHint=true) operation. The description doesn't contradict these annotations, and it adds context by specifying it's a POST request, implying it's an API call that modifies data. However, it doesn't elaborate on behavioral aspects like error conditions, permission requirements, or rate limits beyond what annotations provide.

  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 with a clear header and bullet-pointed parameter list, making it easy to scan. However, the first line '[customRole] customRole.update (POST)' is somewhat redundant with the tool name and could be streamlined, and the content is front-loaded but minimal.

  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 (3 parameters with nested objects, 0% schema coverage, no output schema), the description is incomplete. It lacks details on permission object structure, example usage, error handling, and what the update operation returns. While annotations provide some behavioral context, the description doesn't compensate for the missing schema and output information.

  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 0%, meaning parameters are undocumented in the schema. The description lists parameters (roleName, newRoleName, permissions) and their types/requirements, which adds basic semantics. However, it doesn't explain what 'permissions' object structure entails (e.g., key-value pairs for resource-action mappings) or provide examples, leaving significant gaps in understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool updates a custom role, which is a clear verb+resource combination. However, it doesn't specify what 'update' entails beyond the parameter list, nor does it distinguish this tool from sibling tools like dokploy_customRole_create or dokploy_customRole_remove, which handle creation and deletion of custom roles respectively.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing role to update), when not to use it, or refer to sibling tools like dokploy_customRole_create for creating new roles or dokploy_customRole_remove for deleting roles.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_docker_restartContainerB
  3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide key hints: readOnlyHint=false (implies mutation), destructiveHint=false (non-destructive), idempotentHint=false (non-idempotent), openWorldHint=true (open-world). The description adds minimal behavioral context beyond this, mentioning it's a POST operation, which aligns with annotations but doesn't elaborate on effects like service interruption or permissions. No contradiction with annotations.

  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 brief and front-loaded with the core action ('docker.restartContainer'), followed by parameter listing. It avoids unnecessary fluff, though the parameter section is minimal. It could be more structured but remains efficient.

  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's moderate complexity (a mutation operation with one parameter), annotations cover safety traits, but there's no output schema. The description lacks details on return values, error conditions, or operational impact (e.g., downtime). It's minimally adequate but leaves gaps in understanding the full context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 lists 'containerId (string, required)' but provides no semantic details—what format the ID should be, where to find it, or examples. This adds little value beyond the schema's structural info, failing to address the coverage gap adequately.

  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's purpose: 'docker.restartContainer (POST)' indicates it restarts a Docker container. It specifies the verb (restart) and resource (container), though it doesn't explicitly differentiate from sibling tools like 'dokploy_docker_getContainers' or other container management tools beyond the name prefix.

  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 is provided on when to use this tool versus alternatives. The description lists parameters but offers no context about prerequisites (e.g., container must be running), alternatives (e.g., start/stop tools), or when not to use it. This leaves the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_gitea_getGiteaBranchesB
  3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying it's a GET operation, implying it's a read-only fetch. However, it does not disclose additional traits like rate limits, authentication needs, or what happens if parameters are invalid, leaving some gaps despite the annotations.

  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 and front-loaded with the tool name and HTTP method, followed by a parameter list. It avoids unnecessary details, but the structure could be improved by separating the purpose statement from parameters more clearly. Every sentence (or line) serves a purpose, making it efficient.

  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's low complexity (3 parameters, no nested objects) and rich annotations (covering read-only, non-destructive, idempotent, open-world), the description is somewhat complete. However, with no output schema and 0% schema description coverage, it fails to explain the return format (e.g., list of branch names) or error conditions, leaving the agent with incomplete context for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists parameters (owner, repositoryName, giteaId) with types and required status, adding basic semantics beyond the schema. However, it does not explain what these parameters mean (e.g., owner is the Gitea user/organization, giteaId might be a provider identifier), leaving significant ambiguity for the agent to interpret correctly.

  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's purpose: 'gitea.getGiteaBranches (GET)' indicates it retrieves branches from Gitea. It specifies the resource (Gitea branches) and the action (GET/retrieve). However, it does not explicitly differentiate from sibling tools like 'dokploy_gitea_getGiteaRepositories' or 'dokploy_github_getGithubBranches', which would require mentioning it's specifically for Gitea repositories versus other Git providers.

  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 guidance on when to use this tool versus alternatives. It lacks context about prerequisites (e.g., needing a configured Gitea provider), exclusions (e.g., not for other Git providers like GitHub), or comparisons to sibling tools such as 'dokploy_gitea_getGiteaRepositories'. The agent must infer usage from the tool name and parameters alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_application_readTraefikConfigB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying it's a GET operation, but doesn't disclose rate limits, authentication needs, or what happens if the applicationId is invalid. No contradiction with annotations exists.

  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 brief and front-loaded with the tool name and HTTP method, but it includes redundant formatting (brackets, line breaks) and lacks a clear prose explanation. It's not wasteful, but the structure could be more polished for readability, earning a mid-range score.

  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's low complexity (one parameter) and rich annotations, the description is minimally adequate. However, with no output schema and 0% schema coverage, it fails to explain the return value (e.g., config format) or error conditions. It meets basic needs but leaves gaps in full contextual understanding.

  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 0%, so the schema provides no param details. The description lists 'applicationId' as required but adds no meaning beyond what's in the schema (e.g., format, source, or examples). With one parameter and high schema structural clarity, the baseline is 3, as the description doesn't compensate for the coverage gap but doesn't worsen it.

  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 verb 'read' and the resource 'TraefikConfig' for an application, which is specific and actionable. It distinguishes from siblings like 'dokploy_application_updateTraefikConfig' by indicating a read operation. However, it doesn't fully explain what 'TraefikConfig' entails (e.g., routing rules, middleware settings), leaving some ambiguity.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing application), exclusions, or related tools like 'dokploy_settings_readTraefikConfig' for system-level configs. Usage is implied only by the parameter requirement, with no explicit context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_backup_removeB
  3.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true (implying data loss) and readOnlyHint=false (confirming mutation), which the description aligns with by implying removal. The description adds value by specifying the HTTP method (POST), which isn't covered by annotations, and hints at the parameter structure. However, it doesn't elaborate on behavioral aspects like confirmation prompts, error handling, or irreversible effects beyond what annotations suggest.

  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 brief and front-loaded with the tool name and HTTP method, followed by a parameter list. It avoids unnecessary words, but the formatting (brackets and parentheses) could be cleaner. Overall, it's efficient, though a more structured sentence might improve clarity without adding bulk.

  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's destructive nature (annotations show destructiveHint=true) and lack of output schema, the description is minimally adequate. It covers the basic action and parameter but misses details like return values, error cases, or side effects. With annotations providing safety cues, it's passable but incomplete for a mutation tool, as it doesn't fully guide the agent on outcomes or risks.

  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 0%, so the description must compensate. It lists 'backupId' as a required string parameter, matching the schema, but adds no semantic details (e.g., format, source, or validation rules). Since there's only one parameter, the baseline is 4, but the lack of extra meaning beyond the schema reduces it to 3, as it merely repeats the parameter name without context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool removes a backup ('backup.remove') and specifies it's a POST operation, which clarifies the action and HTTP method. However, it doesn't distinguish this from sibling tools like 'dokploy_backup_delete' (not listed but implied by naming patterns) or other backup-related tools (e.g., 'dokploy_backup_create'), leaving the purpose somewhat vague in context.

  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 guidance on when to use this tool versus alternatives. It lacks context such as prerequisites (e.g., backup must exist), when not to use it (e.g., if backup is in use), or comparisons to other backup tools like 'dokploy_backup_update' or 'dokploy_backup_one'. This absence leaves the agent without usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_compose_deleteB
  3.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying deletion. The description adds minimal context about the deleteVolumes parameter, but doesn't elaborate on behavioral traits like irreversible effects, permissions required, or error conditions. No contradiction with annotations exists.

  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 and front-loaded with the tool name and HTTP method. It efficiently lists parameters without unnecessary details. However, the formatting with brackets and parentheses could be slightly cleaner for 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?

  Given the destructive nature (destructiveHint=true), no output schema, and low schema coverage, the description is insufficient. It doesn't explain the outcome of deletion, error handling, or confirmations. For a high-risk operation, more context is needed to ensure safe usage.

  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 0%, but the description lists parameters and their types, adding basic semantics beyond the schema. It clarifies that deleteVolumes is boolean, but doesn't explain what composeId refers to or the implications of setting deleteVolumes to true/false. With two parameters, this provides some value but leaves gaps.

  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 deletes a compose resource, specifying the required parameters. It distinguishes from siblings by focusing on deletion rather than creation, update, or other operations. However, it doesn't explicitly differentiate from other delete tools like dokploy_application_delete or dokploy_ai_delete.

  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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether the compose must be stopped first, or what happens to associated resources. It doesn't mention when not to use it or refer to sibling tools for related operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dokploy_schedule_deleteB
  3.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide critical behavioral hints: destructiveHint=true (confirms deletion), readOnlyHint=false (confirms mutation), idempotentHint=false (non-idempotent), and openWorldHint=true (may have side effects). The description adds value by specifying the HTTP method (POST), which isn't covered by annotations, and aligns with the destructive nature implied by 'delete'. No contradiction with annotations exists.

  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 brief but inefficiently structured. It includes redundant formatting like brackets and 'POST', and the parameter listing is minimal without added context. While not verbose, it lacks front-loaded clarity and could be more streamlined to convey essential information without clutter.

  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's destructive nature (annotations indicate mutation and destruction) and 0% schema coverage, the description is incomplete. It doesn't explain the outcome of deletion, potential side effects, or error conditions. However, annotations partially fill gaps by hinting at behavior, and no output schema exists, so some context is missing but not critically so.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description only lists 'scheduleId (string, required)' without explaining what a scheduleId is, its format, or where to obtain it. This fails to compensate for the lack of schema documentation, leaving the parameter's meaning unclear.

  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's purpose as 'schedule.delete (POST)', indicating it deletes a schedule resource. It specifies the action (delete) and resource (schedule), though it doesn't explicitly differentiate from sibling tools like dokploy_schedule_update or dokploy_schedule_create beyond the delete action.

  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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing schedule), exclusions, or compare it to related tools like dokploy_schedule_list or dokploy_schedule_update, leaving the agent without contextual usage cues.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.