Update an existing data connection's name, description, credentials, sharing settings, or connection details by ID. Use it to modify data connection configuration in a Hex workspace.
Edit a data connection (name, description, credentials, sharing).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| sharing | No | Sharing config | |
| description | No | ||
| dataConnectionId | Yes | ||
| connectionDetails | No | Updated connection details |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet 'Edit' is the only disclosure. It does not state required permissions, whether unspecified fields are preserved or cleared (patch vs replace), how credential updates are handled, or what sharing changes imply. The mention of 'credentials' is also vague relative to the schema's connectionDetails.
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?
A single front-loaded sentence with no filler — the verb and resource come first and the field list follows. It is efficient, though it is arguably too terse for a five-parameter mutation tool, so conciseness shades into under-specification.
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 no annotations, no output schema, nested objects, and low schema coverage, the description is far too thin. It omits the required identifier, says nothing about partial-vs-full update semantics, permissions, or side effects on credentials and sharing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description should compensate, but it only loosely lists four field areas and omits dataConnectionId — the one required parameter. It also says 'credentials' where the schema says connectionDetails, adding ambiguity rather than precision, and gives no format or nested-object detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource (edit a data connection) and enumerates the editable fields, so an agent can distinguish it from hex-create-data-connection or hex-list-data-connections. It does not, however, explicitly differentiate itself from hex-update-data-connection-schema, which is the nearest sibling and also mutates a connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no named alternatives. The agent must infer that this applies only to existing connections and cannot tell when to prefer this over update-data-connection-schema or create-data-connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.