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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds no behavioral context beyond that — nothing about workspace scoping, behavior on an unknown or inaccessible pipeline_id, or any cross-workspace access rules.

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 a single front-loaded sentence with the verb first, which is good structure. But the long comma-list of data fields is dense and largely duplicated by the output schema, so much of the sentence does not earn its place.

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?

An output schema exists, so explaining return values is unnecessary — yet that is nearly all the description does. The genuinely needed information (workspace_id semantics, relationship to get_pipeline_view and run_pipeline, failure behavior) is missing for a tool in a crowded pipeline-related sibling group.

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 schema itself says nothing about pipeline_id or the optional workspace_id. The description only obliquely implies pipeline selection via 'the selected pipeline' and is completely silent on what workspace_id does or when it should be supplied, so it fails to compensate for the coverage gap.

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 gives a verb ('Read') and resource ('the selected pipeline's active version...'), so the basic operation is discernible. However, the bulk of the sentence enumerates returned data fields rather than stating the purpose, and it never distinguishes this from siblings like get_pipeline_view or list_pipelines, which an agent could easily confuse with it.

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 guidance, no prerequisites, and no mention of alternatives such as list_pipelines (to discover pipelines) or get_pipeline_view (which sounds nearly identical). The word 'selected' hints that an ID must already be known but does not say so.

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