gk_meta

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

With no annotations provided, the description carries the full burden. It discloses a useful behavioral trait: unknown actions return the allowed list, which suggests a safe discovery mechanism. It also implies reading disk configs and facades, but it never states whether actions are read-only or if any have side effects, so transparency is incomplete.

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 sentence that front-loads the core capabilities, then gives invocation syntax and a key behavioral fallback. Every phrase carries information, with no redundant filler.

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 multi-action dispatcher tool with two parameters and no annotations, the description is incomplete. It omits the list of valid action names and what each does, leaving the agent to rely on the unknown-action fallback. The output schema exists, but the inputs are underspecified, making correct invocation difficult.

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 0% and the description adds only minimal parameter meaning: it repeats that 'action' and optional 'args' are used. It mentions '4 actions' but does not list them, and the 'args' object is not described beyond being optional. This is insufficient for an agent to construct valid arguments without external schema info or trial-and-error.

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 what the tool does: it provides honesty status (disk MCP configs + real facades), secrets key listing, and a 9-step plan template/validate. Although it lacks a single explicit verb like 'get' or 'run', the capabilities are concrete and the action-dispatch pattern distinguishes it from siblings like gk_code or gk_guard.

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 gives operational guidance: 'Pass action= and optional args={}' and explains that unknown actions return the allowed list, which helps discover valid actions. However, it doesn't explicitly state when to choose this tool over its siblings, nor does it enumerate the four actions or their intended contexts.

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