list_model_ui_components

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

With readOnlyHint already declaring the safe-read profile, the description still adds real behavioral context: results are bounded by explicit list limits, only IDs and types come back, and unpublished versions are not automatically substituted for published ones. That last point is a non-obvious semantic an agent could easily get wrong, though the actual default limit value is never stated.

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?

Two compact sentences with no filler, and the identity of the resource is front-loaded. Minor density cost from stacked qualifiers ('bounded native saved/unpublished system'), which slightly obscures what is actually being listed.

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?

No output schema exists, so the description reasonably states the return shape (IDs and types), and the readOnly annotation covers safety. For a 6-parameter tool at 0% schema coverage it is still thin: the name_keyword filter, alias behavior, and the default for top are all left for the agent to guess.

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 carry the parameter burden and mostly does not. It gestures at logical_name ('one table'), kind ('forms or views'), and top ('explicit list limits'), but name_keyword has no documented meaning in either place, the logicalName/nameKeyword alias pairs are never explained, and no default or accepted range for top is given.

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?

States a specific verb and resource: list saved/unpublished system forms or views for one table, returning IDs and types. It implicitly separates itself from the singular get_model_ui_component and the mutating edit_model_form/edit_model_view, though it never names them. The phrase 'bounded native saved/unpublished system forms' is dense enough that an agent may need a second read.

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 clause 'no XML or automatic published-version fallback' implies the right contexts (you want IDs, not full definitions; you specifically want unpublished drafts), which hints that get_model_ui_component is the XML alternative. However there is no explicit 'use this when / use X instead' routing and no stated prerequisites for the table.

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