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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered without description help. Beyond that the description discloses nothing — no mention of whether results are paginated, workspace-scoped, or how large the collection may be.

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 short, but the first two sentences are an exact duplicate that conveys zero incremental information. The only substantive content — the describe_operation pointer — is buried at the end rather than front-loaded.

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 list endpoint with nested-object parameters, no output schema, and 0% schema coverage, an agent needs at least what resource is returned and how to filter or page it. The description provides none of that and only delegates to another tool, so it is insufficient to call this tool correctly without further exploration.

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 two parameters (a free-form `query` object and an empty `params` object), and the description supplies no information about what those parameters accept or how to filter view layouts. The description's only parameter-related sentence just redirects to describe_operation, leaving semantics entirely undocumented.

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 merely restates the title and HTTP path ("GET /api/view-layouts. GET /api/view-layouts."), so the only clue to purpose is the resource name embedded in the URL. It gives no indication of what a view layout is, what it contains, or how it differs from siblings such as get_view_layouts_by_module_by_viewType_4f82e2efbf5b2909263e30bf.

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 only guidance is a pointer that "describe_operation provides native request schemas," which tells the agent how to inspect the tool but not when to use it. There is no mention of when to prefer this listing over the module/viewType-scoped siblings, nor any preconditions or filtering context.

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