Get GitLab pipeline

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, covering the main safety aspects. The description adds the return field list, which is useful but not beyond the annotations. There is no contradiction between description and annotations, and the description does not disclose additional behavioral details like error handling or rate limits, but given the simplicity of the operation, this is adequate.

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, concise sentence that directly states the purpose and lists the key returned fields. There is no redundancy, fluff, or unnecessary detail, making it highly efficient and well-structured.

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?

The description provides a clear overview of what the tool does and what it returns, which is sufficient for a simple read operation. It does not include an output schema or error cases, but given that these are not provided in the schema either, and the annotations cover safety, the description is adequately complete for typical usage. The lack of explicit context about when to use it is the only minor gap.

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?

The schema provides a description for the 'project' parameter but not for 'pipeline_id', resulting in only 50% coverage. The tool description does not compensate for this gap, as it does not mention parameters at all. Thus, the semantics for the pipeline_id parameter are unclear, especially since it is required. This weakens the parameter understanding.

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 clearly states that the tool retrieves a single pipeline and explicitly lists the fields it returns (status, duration, coverage, ref, user, timestamps). It is distinct from list_pipelines (which retrieves multiple) and get_latest_pipeline (which retrieves the latest), making the purpose unambiguous.

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 does not explicitly state when to use this tool versus alternatives like list_pipelines or get_latest_pipeline. However, the name 'get_pipeline' and the description 'Get one pipeline' strongly imply that it is for fetching a specific pipeline by ID, which is a reasonable implicit guidance. Still, explicit differentiation would improve the score.

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