Dokploy MCP Server

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.

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.

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.

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.

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.

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.