Skip to main content
Glama

merjax_get_workflow_logs

Read-only

Return a workflow run's logs plus a failure summary. Always includes run metadata (number, workflow, event, ref, sha), per-job and per-step status / exit code / duration, failedSteps (job / step) and testFailures (failing test names, read from each step's structured results parsed before its log was cut, or the reason they cannot all be named; null when no job failed). testFailures.details marks each failure flaky (an active forensic label with a repro, from another run — with its label and flip rate), known (also failing on the default branch's latest run), infra (timed out under load) or new, with its file, message, the targeted retry's verdict and this run's determinism-forensics finding (forensic: class, label, variable, repro) when they ran. A step whose log was cut carries fullLog (artifact download of the uncut output). step (a step name or 1-based position within its job) returns only that step's stdout/stderr; tail_lines keeps the last N lines. The full per-job logs are included only when neither is given. JSON-friendly companion to the ZIP-download endpoint. A private repository's logs require 'repo' scope (OAuth: write:repo); every token read is audited. For a read-only CI audit credential, a repository token with {"runners": "read", "actions": "read"} (the ci-audit preset, merjax_create_repo_token) reads the same masked logs over REST — GET /api/v2/repos/:owner/:repo/actions/runs/:id/logs, or one job's at actions/jobs/:job_id/logs — under the same rule and audit; repository tokens are not accepted on /mcp.

Input Schema

NameRequiredDescriptionDefault
repoYes
stepNoOnly this step's logs: its name (exact, else substring, case-insensitive) or its 1-based position within its job
ownerYes
run_idYesThe run's id, or a unique leading part of it (8+ hex characters)
tail_linesNoKeep only the last N lines of each returned log (max 5000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/destructiveHint, yet the description adds substantial behavior beyond them: 'repo' scope / write:repo OAuth requirement, per-token audit logging, masked logs, truncation with a `fullLog` artifact fallback, and the rule that repository tokens are not accepted on /mcp. That is exactly the auth, audit and data-truncation context an agent cannot get from the schema.

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

Conciseness3/5

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

Purpose is front-loaded in the first sentence, but the body is one dense paragraph with deeply nested parentheticals covering the flaky/known/infra/new taxonomy and forensic metadata. That content is needed given there is no output schema, yet it is packed into a wall of text rather than separated into readable structure.

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

Completeness4/5

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

With no output schema, the description carries the return-shape burden and does so thoroughly — run metadata, per-job/per-step status, failedSteps, testFailures and fullLog are all defined. Gaps remain around failure modes (unknown run_id, non-unique prefix) and any size/pagination limits on returned logs.

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 60% (owner and repo are undocumented), so the description must compensate. It does so by explaining the interaction the schema omits: full per-job logs only when neither `step` nor `tail_lines` is given, plus `step` accepting a name or 1-based position and `tail_lines` capping at 5000 lines. The owner/repo parameters still carry no added meaning.

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

Purpose4/5

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

The opening sentence gives a specific verb and resource ('Return a workflow run's logs plus a failure summary') and the 'JSON-friendly companion to the ZIP-download endpoint' line scopes it against a non-MCP alternative. It never names a sibling such as merjax_get_workflow_run or merjax_explain_failure, so an agent still has to infer the boundary against those.

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

Usage Guidelines4/5

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

The description gives clear conditional usage internally: passing `step` returns only that step's output, `tail_lines` keeps the last N lines, and full per-job logs are returned only when neither is supplied. It also spells out the credential path for read-only CI audit (ci-audit preset or REST endpoints). It stops short of excluding any sibling tool explicitly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources