platform_auth_probe

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

With no annotations, the description carries the full burden. It adds the key behavioral disclosure that it does not return credentials, which is not inferable from the name alone. However, it does not specify return format, error behavior, or side effects, so it does not fully cover all transparency needs.

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, focused sentence with no redundant words. It immediately states the action and the key limitation, earning every word.

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 simple one-parameter tool, the description covers the core behavior but omits expected output details (e.g., boolean vs error) and any context about why one would probe auth. Since there is no output schema, the agent is left guessing about the return format, making this moderately complete but not fully sufficient.

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 0%, so the description must compensate. It does not mention the 'platform' parameter or its possible values. While the schema provides an enum, the description adds no additional meaning about how to select or interpret the platform values, leaving the agent to infer from the tool name.

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 the specific verb 'Check' with a clear resource ('platform adapter') and outcome ('whether authenticated'). It also distinguishes itself from siblings by adding the safety constraint 'without returning credentials' and the focus on auth state, which is distinct from the publishing workflow tools.

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 implies its use case (checking auth before publishing) but provides no explicit when-to-use vs alternatives or exclusions. Context signals show siblings, but the description does not reference them. For a simple one-parameter tool, the usage is fairly obvious, but the lack of explicit guidance keeps it at a minimum viable score.

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