Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

get_pipeline_step_logs

Read-only

Why did an Ankra Pipelines step fail? Reads a pipeline run and one step's archived log tail. Address the run by execution_id (each agent-run pipeline step is its own execution in list_recent_executions), run_id (a UUID), or owner and repo: run_number (run #3630), else the newest run narrowed by branch, pull_request or head_sha (recent_runs lists ten). Find a pull request's run by pull_request, not branch (refs/pull/622/merge reads as pull_request 622). The step read is step (key or display name), else the execution's, else the first failing one. Returns the run (repository, ref, sha, outcome, cluster), each step's outcome and exit code, and log.state: available (text = last max_lines lines), not_archived, or unavailable (unknown, not empty). Read-only; needs pipelines.read. Ankra Pipelines runs are not GitHub Actions runs.

Input Schema

NameRequiredDescriptionDefault
repoNoRepository name, with owner.
stepNoStep key or display name whose log to read. Defaults to the execution's step, else the run's first failing step.
ownerNoRepository owner, with repo; repo may also be owner/name.
branchNoWith owner/repo: only runs of this branch (a pull request run's is its base).
run_idNoA run's UUID (a run number is read as run_number).
head_shaNoWith owner/repo: only runs of this full commit SHA.
providerNoSource control provider of owner/repo: github, gitlab, or bitbucket_cloud. Defaults to github.
max_linesNoTrailing log lines to return, 1-400; default 150.
run_numberNoWith owner/repo: the number shown as run #3630.
execution_idNoAn execution id from list_recent_executions or get_execution_details.
pull_requestNoWith owner/repo: only this pull request's runs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / branch / description
      Previous value: -"With owner/repo: only runs of this branch."New value: +"With owner/repo: only runs of this branch (a pull request run's is its base)."
    • addedInput schema / properties / head_sha
      Added value: +{
+  "description": "With owner/repo: only runs of this full commit SHA.",
+  "type": "string"
+}
    • addedInput schema / properties / pull_request
      Added value: +{
+  "description": "With owner/repo: only this pull request's runs.",
+  "type": "integer"
+}
    • changedInput schema / properties / run_id / description
      Previous value: -"A pipeline run id."New value: +"A run's UUID (a run number is read as run_number)."
    • addedInput schema / properties / run_number
      Added value: +{
+  "description": "With owner/repo: the number shown as run #3630.",
+  "type": "integer"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses the required permission ('needs pipelines.read') and, unusually, the behavioral semantics of the return payload: log.state can be available (text = last max_lines lines), not_archived, or unavailable, and unavailable means unknown rather than empty. That distinction is exactly the operational nuance an agent needs to avoid misreading an empty log.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the user-facing question, and each subsequent sentence carries addressing, defaults, or return semantics rather than filler. It is dense and long for a single paragraph, which costs it a point, but nothing reads as padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 optional parameters, no required fields, and no output schema, the description compensates fully: it enumerates the run fields returned (repository, ref, sha, outcome, cluster), the per-step outcome and exit code, and the log state machine. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds two things the schema does not: the resolution precedence between the three run-identifier families, and the note that a refs/pull/622/merge ref surface as pull_request 622 rather than branch. The step default chain is largely a restatement of the schema's own defaults, which caps this below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with the diagnostic question the tool answers and states a specific verb+resource: reads a pipeline run plus one step's archived log tail. It explicitly distinguishes itself from the crowded sibling set by noting 'Ankra Pipelines runs are not GitHub Actions runs', separating it from github_get_job_logs and get_pod_logs without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit addressing precedence (execution_id, run_id, owner+repo run_number, else newest run narrowed by branch/pull_request/head_sha, with recent_runs listing ten) and an explicit routing rule for the common trap: 'Find a pull request's run by pull_request, not branch'. The step-selection fallback chain (step, else execution's, else first failing) is likewise spelled out.

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

All Ankra toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources