Inspect native input and selectable fields

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — 'No credentials or request' — implying a purely local introspection with no upstream call, though the wording is ambiguous about whether it means no auth or no request body. It says nothing about cost, caching, or when the returned schema can go stale.

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?

It is very short and front-loads the resource ('input schema'), which is good, but the second sentence is a compressed fragment list ('every selectable upstream field path and bounded default selections') that reads as telegraphic rather than economical. Brevity here costs clarity rather than buying it.

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?

With one enum parameter, no output schema, and no nested objects, the tool is simple, but its entire value is the shape of what it returns (field paths and default selections) and the description only gestures at that. An agent can call it, but cannot predict the response structure or know how to use the returned paths, which is the core of the tool.

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% for the single required 'operation' parameter, so the description must carry the burden and does not. It alludes to 'current operation' but never states that the argument must be one of the 36 enumerated operation names or how those enum values relate to the sibling tools (e.g. 'posts' vs get_posts).

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 title verb 'Inspect' plus the phrase 'input schema' makes the general purpose recoverable, but 'Local current operation input schema' is awkward and never says plainly that the tool returns the request schema for a named operation. It also fails to distinguish itself from siblings such as preview_operation or graphql_query, which an agent would need in order to choose correctly.

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 statement, no precondition, and no named alternative. The description never explains that this is a discovery step to run before constructing an operation, nor why one would call it instead of reading a sibling tool's schema directly.

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