Get Db Credentials

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses that the operation reads from the actual running environment at call time, implying real-time state and no mutation. This additional behavioral detail (resolved env vs. template) gives the agent a more accurate mental model of the tool's effects and data source.

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 two terse sentences with no redundant words. It delivers the core purpose and a key nuance in a compact, well-structured manner, making it easy to read and parse.

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?

Given the moderate complexity (5 parameters, no output schema), the description conveys the core purpose and emphasizes the live-environment source, but lacks details about the return value's structure (e.g., which credential fields are included) and does not explain the remaining parameters. However, the purpose is clear enough for a simple read operation, so it is mostly complete.

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?

The description only explains the `component` parameter (a compose service running a database). The other four parameters (`workspaceSlug`, `appSlug`, `env`, `region`) are left entirely undocumented, and the schema provides no descriptions either. With zero schema coverage, the description must compensate for all parameters, which it does not.

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 that the tool reads from the running pod's resolved environment at call time to obtain database credentials, and it explicitly notes that the container is the source of truth rather than the template. This makes the tool's purpose unambiguous and distinct from actions that might operate on config or template state.

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 a clear semantic contrast—'source of truth rather than the template'—which implicitly tells the agent when to use this tool (when live environment credentials are needed, not the template-defined ones). It does not explicitly state alternative tools to use in other scenarios, but the guidance is sufficient for a basic call.

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