datailo_disableDisable a service: revokes the hub's key for it. Your account and data there remain yours.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| session | No | The `session` value datailo_connect_verify returned. Pass it on every Datailo call in this conversation; omit it when the user connected with Sign in (OAuth) or a key. |
Changes observed during successful MCP inspections.
Input schema / properties / session / descriptionPrevious value: -"The `session` value datailo_connect_verify returned, when this client keeps no connection session. Pass it on every Datailo call in this conversation; omit it when the user connected with Sign in (OAuth) or a key."New value: +"The `session` value datailo_connect_verify returned. Pass it on every Datailo call in this conversation; omit it when the user connected with Sign in (OAuth) or a key."Input schema / properties / sessionAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The `session` value datailo_connect_verify returned, when this client keeps no connection session. Pass it on every Datailo call in this conversation; omit it when the user connected with Sign in (OAuth) or a key.",
+ "title": "Session"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's mention of 'revokes the hub's key' adds a specific mechanism but does not contradict annotations. The description adds the reassurance that data remains with the user, which is valuable context beyond the generic mutation warning. However, it doesn't disclose any side effects on connected workflows or other services. No contradiction.
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 one sentence with zero waste. It front-loads the purpose and includes the key behavioral guarantee ('Your account and data there remain yours.') in an efficient manner. The structure is exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with destructiveHint=true and no output schema, the description covers the core action and reassures about data retention. The sibling context and the 'session' parameter are adequately handled through schema and naming. It could mention if the operation is reversible, but the 'disable' concept implies it can be re-enabled via 'datailo_enable'. Overall, it is complete enough for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with the 'session' parameter being fully described in the schema. The description itself does not elaborate on the 'service' parameter, but the schema title and the description's context make it clear that 'service' refers to the service to disable. Since the schema covers the nuanced session parameter well, the description doesn't need to add much, yet it provides enough context for the required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Disable' and the resource 'a service', and explains the mechanism ('revokes the hub's key for it'). It distinguishes this from the sibling tool 'datailo_enable' by the opposite action, though it does not explicitly name the sibling. A clear and specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is used for disabling services but provides no explicit guidance on when to use it versus the sibling 'datailo_enable' or other tools. The description is clear on the action but not on selection criteria, which is acceptable since the tool name and title are self-explanatory, but it lacks an explicit 'when to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.