Get effective configuration

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

Annotations already mark the operation as read-only and idempotent, so the description does not need to restate safety. It adds useful behavioral context beyond the annotations: secrets are always redacted, and each field includes provenance (env, file, or default). This meaningfully informs the agent about what to expect from the response.

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 a single dense, front-loaded sentence followed by two crisp notes on provenance and redaction. Every clause adds a distinct piece of useful information, with no filler or repetition of the title.

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 zero-parameter, read-only inspection tool, the description covers what is reported, where the values come from, and the redaction guarantee. Since there is no output schema, enumerating the config categories is sufficient for an agent to know exactly what it will get back.

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 tool has zero parameters and the schema is empty, so the parameter-semantics burden is minimal. The description credits that this is a no-input snapshot operation, and there is nothing else the description must explain about arguments.

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 uses a specific verb ('Show') with a precise resource ('configuration this server is using right now') and enumerates exactly which fields are reported, from version and endpoints to auth mode and dry-run default. It clearly differentiates itself as the effective configuration view rather than a generic configuration tool.

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?

With no sibling tools, there is no alternative to contrast, but the description gives clear context for when it should be used: when you need the server's currently effective configuration and its value sources. It does not over-explain invocation prerequisites, but the read-only, inspect-this-state framing is evident.

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